932
edits
Changes
Bringing in the encrypted email connections from the old lab 4d.
==OBJECTIVE & PREPARATION==
{{Admon/important|Prerequistites|This lab depends on changes made in several previous labs. You must have successfully completed labs 3, 4a, 4b, and 5 in order to be able to do this lab.}}
Below is the same diagram that we referred to over the previous 2 email labs:
[[Image:Email-servers.png]]
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 <u>truly</u> 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.
=== Online Resources===
* [https://en.wikipedia.org/wiki/Transport_Layer_Security TSL, SSL Definition]* [https://www.e-rave.nl/create-a-self-signed-ssl-key-for-postfix Create a self signed SSL key for Postfix]* [http://wiki2.dovecot.org/SSL/DovecotConfiguration Dovecot SSL configuration] == INVESTIGATION 1: GENERATING A SELF-SIGNED CERTIFICATE == According to Wikipedia (Course Notes 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 statement but that is mainly 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 [https://www.e-rave.nl/create-a-self-signed-ssl-key-for-postfix 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 ([http://zenit.senecac.on.ca/wiki/index.php/OPS335_Lab_1#SSH_Keys 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:''' #Let's start with the "sending" SMTP server we have on Samba VM2. Run the following, replacing <u>andrewsmith.org</u> with '''<u>your</u> domain name''': <source lang="bash">mkdir -p /root/postfix-keys /etc/ssl/{private,certs}cd /root/postfix-keysopenssl genrsa -des3 -out vm2.andrewsmith.org.key 2048chmod 600 vm2.andrewsmith.org.keyopenssl req -new -key vm2.andrewsmith.org.key -out vm2.andrewsmith.org.csropenssl x509 -req -days 365 -in vm2.andrewsmith.org.csr -signkey vm2.andrewsmith.org.key -out vm2.andrewsmith.org.crtopenssl rsa -in vm2.andrewsmith.org.key -out vm2.andrewsmith.org.key.nopassmv vm2.andrewsmith.org.key.nopass vm2.andrewsmith.org.keyopenssl req -new -x509 -extensions v3_ca -keyout cakey.pem -out cacert.pem -days 3650chmod 600 vm2.andrewsmith.org.key cakey.pemcp vm2.andrewsmith.org.key cakey.pem /etc/ssl/privatecp vm2.andrewsmith.org.crt cacert.pem /etc/ssl/certs</source> ::'''NOTE:''' Those commands will create a certificate, a certificate signing request, a certificate authority, and sign your certificate with your certificate authority.<br>This would be the same as in the real world except there you would contact a real CA, here you're making up your own. <ol><li value="2">Now, configure Postfix to use the generated certificate, by adding the following to your '''main.cf''' file:</li></ol> <pre># Settings to enable secure SMTP using my self-signed certificate:smtpd_tls_auth_only = nosmtpd_use_tls = yessmtp_use_tls = yessmtpd_tls_key_file = /etc/ssl/private/vm2.andrewsmith.org.keysmtpd_tls_cert_file = /etc/ssl/certs/vm2.andrewsmith.org.crtsmtpd_tls_CAfile = /etc/ssl/certs/cacert.pemtls_random_source = dev:/dev/urandomsmtpd_tls_loglevel = 1</pre> === Setting Up and Testing Encryption with Thunderbird === '''Perform the following steps:''' #Currently your Thunderbird is set up to use '''vm2.yoursenecaid.org''' for an SMTP server, with <u>no</u> 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;therefore, leave the '''authentication method''' at the value: '''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: [[Image:SMTP-certificate-warning.png]] ::'''NOTE:''' Your message may look slightly different (This author, that created the diagram above, made a little mistake when generating the certificate). <ol><li value="4">After you confirm that security exception, send another email to yourself and make sure you receive it.</li><li> 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.</li></ol> === Encryption Dovecot with Secure Socket layer (SSL) === Now we will ensure that our '''Dovecot''' connection is secure, and enforce that policy. With SMTP, you will need to allow plain text connections since that is the only method to pass email from server-to-server. With IMAP, there is no server-to-server interaction, but rather only client-to-server interaction. The reason to have an unencrypted IMAP connection would be if your '''IMAP server''' and '''IMAP client''' were the <u>same</u> machine (this would be the situation when using webmail). '''Perform the following steps:''' # Let's start by generating a new certificate for Dovecot on your vm3 machine by issuing the following commands:<source lang="bash">mkdir /etc/ssl/{private,certs}openssl genrsa -des3 -out vm3.andrewsmith.org.key 2048chmod 600 vm3.andrewsmith.org.keyopenssl req -new -key vm3.andrewsmith.org.key -out vm3.andrewsmith.org.csropenssl x509 -req -days 365 -in vm3.andrewsmith.org.csr -signkey vm3.andrewsmith.org.key -out vm3.andrewsmith.org.crtopenssl rsa -in vm3.andrewsmith.org.key -out vm3.andrewsmith.org.key.nopassmv vm3.andrewsmith.org.key.nopass vm3.andrewsmith.org.keyopenssl req -new -x509 -extensions v3_ca -keyout cakey.pem -out cacert.pem -days 3650chmod 600 vm3.andrewsmith.org.key cakey.pemcp vm3.andrewsmith.org.key cakey.pem /etc/ssl/privatecp vm3.andrewsmith.org.crt cacert.pem /etc/ssl/certs</source> ::'''NOTE:''' This 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 (i.e. you can share the certificate between them). In our case, they are not on the same machine. <ol><li value="2">Next, we need to configure Dovecot to use this for encrypted connections and not allow any kind of plain text connections. Edit the '''dovecot.cont''', '''10-auth.conf''', <u>and</u> '''10-ssl.conf''' files and change the following settings:</li></ol> <source lang="bash">ssl = requiredssl_cert = <path_to_your_crt_filessl_key = <path_to_your_key_filedisable_plaintext_auth = yesprotocols = imaps (instead of imap)</source> <ol><li value="3">Your key/certificate doesn't have a '''.pem''' extension but they are PEM-encoded files. You can confirm that using the '''file''' command. If you're interested, learning more about configuring Dovecot for SSL, refer to the following documentation: [http://wiki2.dovecot.org/SSL/DovecotConfiguration Dovecot SSL configuration].</li></ol> === Verifying that Mail Messages are Encrypted=== '''Perform the following steps:'''
#Use the '''ss''' command to confirm you're only listening on the '''imaps''' port, and not the plain imap port.
#Next, reconfigure your account settings in Thunderbird to use the '''SSL/TLS''' connection security with your IMAP server.
'''Record steps, commands, and your observations on this investigation in your OPS335 lab log-book'''
