OPS335 Lab 4d

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.

The public key cryptography concepts are the same in this lab as the SSH lab, but the terminology is slightly different. A simple way to look at it is:

• Your .key file is your private key.
• Your .crt file is your public key.

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:

cd /root/postfix-keys
openssl genrsa -des3 -out vm2.andrewsmith.org.key 2048
chmod 600 vm2.andrewsmith.org.key
openssl req -new -key vm2.andrewsmith.org.key -out vm2.andrewsmith.org.csr
openssl x509 -req -days 365 -in vm2.andrewsmith.org.csr -signkey vm2.andrewsmith.org.key -out vm2.andrewsmith.org.crt
openssl rsa -in vm2.andrewsmith.org.key -out vm2.andrewsmith.org.key.nopass
mv vm2.andrewsmith.org.key.nopass vm2.andrewsmith.org.key
openssl req -new -x509 -extensions v3_ca -keyout cakey.pem -out cacert.pem -days 3650
chmod 600 vm2.andrewsmith.org.key cakey.pem
cp vm2.andrewsmith.org.key cakey.pem /etc/ssl/private/
cp vm2.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.

Now configure Postfix to use it, by adding the following to your main.cf file:

# Settings to enable secure SMTP using my self-signed certificate:
smtpd_tls_auth_only = no
smtpd_use_tls = yes
smtp_use_tls = yes
smtpd_tls_auth_only = no
smtpd_tls_key_file = /etc/ssl/private/andrewsmith.org.key
smtpd_tls_cert_file = /etc/ssl/certs/andrewsmith.org.crt
smtpd_tls_CAfile = /etc/ssl/certs/cacert.pem
tls_random_source = dev:/dev/urandom
smtpd_tls_loglevel = 1

Test with Thunderbird

Currently your Thunderbird is set up to use vm2.yoursenecaid.org for an SMTP server, with no security. Change that to use STARTTLS instead (you can change it under account settings --> Outgoing Server). We haven't set up any user authentication, just an encrypted channel - so leave the authentication method at none.

Thunderbird will warn you about the self-signed certificate. You obviously know it's your certificate so you can tell Thunderbird to trust it:

Your message may look slightly different, I made a little mistake when generating my certificate.

After you confirm that security exception - send another email to yourself and make sure you receive it. Notice that from the user's point of view nothing is different. But if you were an evildoer trying to steal an identity - the difference is huge. Before it was trivial and now it's computationally prohibitive.

Dovecot + SSL

Now we'll ensure our Dovecot connection is secure, and we'll enforce that. With SMTP you need to allow plain text connections because that's the only way to pass email server-to-server. With IMAP there is no server-to-server, only client-to-server. The only reason to have an unencrypted IMAP connection would be if your IMAP server and IMAP client were the same machine (this would be the case with webmail).

Let's start by generating a new certificate for Dovecot on vm3:

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

The process is identical to what you've done for the vm2 certificate. In fact if your IMAP and SMTP servers are on the same machine - you can share the certificate between them. In our case they're not on the same machine.

Now we need to configure Dovecot to use this for encrypted connections and not allow any kind of plain text connections. Edit 10-auth.conf and 10-ssl.conf to change the following settings:

• ssl = required
• ssl_cert = <path_to_your_crt_file
• ssl_key = <path_to_your_key_file
• disable_plaintext_auth = yes

Your key/certificate don't have a .pem extension but they are PEM-encoded files. You can confirm that using the file command. If you're interested - here's some documentation about Dovecot SSL configuration.