OPS335 Lab 4d

LAB RESOURCES

Online References:

OVERVIEW (ENCRYPTING EMAIL CONNECTIONS)

Below is the same diagram that we have been referring to over the past 2 email labs:

Note the two globes in the above diagram. Those globes represent the Internet that your emails travel through in order to be received by an e-mail recipient. The smaller globe (the one your workstation is connected to) cannot be trusted to send mail messages unencrypted. The larger globe usually involves inter-ISP traffic, often through an internet trunk line, so it is also unencrypted, but it cannot be easily accessed by hackers, pen-testers, or evildoers.

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

• 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 truly secure. But attempting to continually 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.

• Email travelling over a LAN (especially Wifi, but any local network) is always encrypted.

If e-mail traffic on a LAN was not encrypted, it would be easy and inexpensive to intercept (in order to obtain your username and password). These days, unencrypted connections from your client to your SMTP/IMAP/POP3 server very rarely exist.

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.

INVESTIGATION 1: GENERATING A SELF-SIGNED CERTIFICATE

According to Wikipedia (https://en.wikipedia.org/wiki/Transport_Layer_Security), Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), both of which are frequently referred to as 'SSL', are cryptographic protocols designed to provide communications security over a computer network.

Normally (in production), you would need to pay a "certificate authority" to issue a certificate for you. That is essentially a "signed" public key that will tell strangers on the internet that your server is really yours (i.e. the certificate authority says so). There is an obvious problem with the previous statemen,t but that is mainlyy how public key encryption works on the Internet today.

We will be generating our own public keys, mainly in order to avoid paying for a certificate. We will not have enough time to get into the details of what all the following commands do in this section. They are from this blog post. If you don't understand what the blog post refers to but would like to understand in more details, a good recommended book for interest, called Crypto by Steven Levy, provides a more in-depth discussion of encryption and security.

The public key cryptography concepts in this lab are the same in a previous lab (Lab1: SSH), although the terminology is slightly different.

A simple way to summarize the differences is:

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

Encrypting Postfix with Transport Layer Security (TLS)

Perform the following steps:

1. 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/

NOTE: 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.

2. 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

Setting Up and Testing Encryption 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.

Encryption Dovecot with Secure Socket layer (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
• protocols = imaps (instead of imap)

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.

Test

Use netstat to confirm you're only listening on the imaps port, and not the plain imap port. Then reconfigure your account settings in Thunderbird to use SSL/TLS connection security with your IMAP server. You'll get a warning because you're using a self-signed certificate, authorise the exception.

Record steps, commands, and your observations in INVESTIGATION 1 in your OPS335 lab log-book

INVESTIGATION 2: OTHER EMAIL CONSIDERATIONS (NOT COVERED IN THIS LAB)

If you got to this point and everything worked (and you understand what you've done) - congratulations, you have set up a working email server and you can now have an intelligent conversation with an employer about this hugely important system.

But be aware that even though we spent three weeks on it - we've only done the simplest possible setup. In the rest of the section we'll list other commonly-needed services/tools/concepts that we just don't have time for this semester.

Open Relays

Your SMTP servers are open relays. That means if they were accessible on the internet - anyone could use them to send spam. This would very quickly get your server blacklisted and you'd have a very hard time getting yourself off that blacklist.

There are two common solutions for that:

1. Restrict your "sending" SMTP server to only work on your network. ISPs commonly do this. This doesn't work very well if you have mobile clients (laptops, phones) which are not always connected to your ISPs network.
2. Use SASL or some other means of checking that the person trying to use the SMTP server has a valid user on the system. This way only your users will be able to use your server to relay email.

SPF

SPF uses DNS to publish a list of server IP addresses that are allowed to send email for your domain. That way a receiving server can check whether the sending server is authorized (message is likely not spam) or not (message is probably spam).

SPF is a pretty cool system, but it's not perfect. It works very well for single servers but if you send mail for your domain from multiple servers (and perhaps a varying number of them) - you have to put in wildcards which lower the effectiveness of this system.

DKIM

One popular spam-prevention measure that uses encryption to sign messages originating from your server so that receiving servers can verify that the messages really did come from your server (the keys are published in DNS).

It's a neat idea but the strength of the encryption is pretty pathetic. So it's a good deterrent against mass amounts of spam, but it doesn't really guarantee anything.

Address Books

An address book has nothing to do with email, even though you might think they are related systems. Typically an address book is a completely separate system - using either a CardDav server (one easy to set up comes with OwnCloud) or an LDAP server. Even tightly integrated services like Microsoft's Active Directory keep the address book separate from the email.

Vacation Responders

If you think about it - it's not really clear what service should be responsible for sending out vacation messages. Your receiving SMTP server? Do you really want your users to be able to control that? The client? It's probably not running.

It's usually yet another separate service. Even though the settings to enable vacation response will usually be next to your other email settings - they will be controlling a separate system that's hooked into your MTA.

Other Stuff

There are countless other features and extensions for email. Not to mention propietary ones like Gmail, Yahoo mail, Office 365, etc. But having mastered the email portion of this course - you will be qualified to evaluate capabilities, design integrated systems, and customise the email service for you organization like no regular email user can even understand.

Note important considerations not covered in this INVESTIGATION into your OPS335 lab log-book

COMPLETING THE LAB

Students should be prepared with all required commands (system information) displayed in a terminal (or multiple terminals) prior to calling the instructor for signoff.

Arrange evidence (command output) for each of these items on your screen, then ask your instructor to review them and sign off on the lab's completion:

✓Thunderbird with a message sent and received using encrypted channels.

✓New Thunderbird server configuration for your account.

✓Logs on vm2 and vm3 showing the message has been sent and received.