Open main menu

CDOT Wiki β

OPS335 Lab 4d

Revision as of 01:50, 5 March 2016 by Andrew (talk | contribs) (Encrypting Email Connections)

Encrypting Email Connections

This is the same diagram of the setup we've been working on for the last two weeks:

 

Note the two globes in the diagram - those are two networks your emails need to traverse. Usually both are the internet, but the smaller one (the one your workstation is connected to) cannot be trusted at all. The bigger one usually involves inter-ISP traffic, often through an internet trunk line, so it's equally unencrypted but not as easily accessed by evildoers.

There are two important general truths you need to understand about email encryption:

  1. Email (the way the vast majority of people use it) travels from SMTP server to SMTP server uncencrypted. That means that nothing sent over email is ever truly secure. But intercepting SMTP server to SMTP server traffic is difficult and expensive, not worth doing for the little bit of money most of us have in our bank account.
  2. Email travelling over a LAN (especially Wifi, but any local network) is always encrypted. If it weren't - that is so easy and cheap to intercept that you're just asking for someone to please take your passwords and steal your identity. These days unencrypted connections from your client to your SMTP/IMAP/POP3 server are practically unheard of.

You see in our diagram that one of the SMTP connections is supposed to be encrypted (this is the one that would be "LAN" traffic) and the IMAP connection as well (this one is either LAN-like traffic or is connecting to localhost, which is a different scenario altogether).

We're going to secure the two connections that we left to be in plain text previously. Unfortunately encrypting things is rarely a straighforward process. Fortunately we have a whole week to spend on it.

Generating a Self-signed Certificate

Normally (in production) you need to pay a certificate authority to issue a certificate for you. That's essentially a signed public key that will tell strangers on the internet your server is really yours (the certificate authority says so). There's an obvious problem with the previous statement but that's mostly how public key encryption works on the internet today.

We'll be generating our own, mostly in order to avoid paying for the certificate. We won't have too much time to get into the details of what all the following commands do. They are from this blog post. If you don't understand what he's talking about on that page but would like to understand - I'll again recommend the book Crypto by Steven Levy for reading outside this course.

Postfix + TLS

Let's start with the "sending" SMTP server we have on VM2. Run the following, replacing andrewsmith.org with your own domain name:

openssl genrsa -des3 -out andrewsmith.org.key 2048
chmod 600 andrewsmith.org.key
openssl req -new -key andrewsmith.org.key -out andrewsmith.org.csr
openssl x509 -req -days 365 -in andrewsmith.org.csr -signkey andrewsmith.org.key -out andrewsmith.org.crt
openssl rsa -in andrewsmith.org.key -out andrewsmith.org.key.nopass
mv andrewsmith.org.key.nopass andrewsmith.org.key
openssl req -new -x509 -extensions v3_ca -keyout cakey.pem -out cacert.pem -days 3650
chmod 600 andrewsmith.org.key cakey.pem
cp andrewsmith.org.key cakey.pem /etc/ssl/private/
cp andrewsmith.org.crt cacert.pem /etc/ssl/certs/

Those commands will create a certificate, a certificate signing request, a certificate authority, and a sign your certificate with your certificate authority. Same as in the real world except there you would contact a real CA, here you're making up your own.