Lab 7 - Transport Layer Security (TLS)¶

Nowadays, everything is on the internet. Not only cat pictures but also financial institutions, mail services, schools, and even the government.

The problem is, that as a person, you usually do not want someone else to read your private emails or access your bank account. Especially if that someone has malicious intent.

This is entirely the job of System Administrators. They try to protect the privacy of data. Thankfully, to make their job easier, mathematicians have come up with a technology called asymmetric cryptography.

Asymmetric cryptography allows you to generate a pair of certificates - usually called certificate and key. The key is secret, you never let anyone know the key. But you do let them know the certificate.

Then, when anyone wants to send you anything private, they take your certificate and encrypt the data they want to send with this certificate. Now, after encryption, the only way to decrypt this data is using your key. This is the same idea SSH keys use.

The same concept can be used, when you are hosting your services. You can take a certificate/key pair, and tell the Apache web server to use this pair. This means, that any time someone connects to Apache, they are given a public certificate to encrypt their information with. When they encrypt and send their data to the server, the server takes the private key and decrypts the data. This allows you to exchange data with a server while remaining completely safe from prying eyes.

For example, you can see Google's public certificate by doing: openssl s_client -connect google.com:443 Under the server certificate section, you can see the public certificate.

Now that certificates have entered the picture, there is yet another security issue. If everyone could generate a certificate/key pair for any web service, then it would be very easy to fake a web server, for example, a bank. To prevent this, these certificate/key pairs are made in the following steps:

• Generate a private key
• Create a certificate request based on this key
• Send the certificate request to a Certificate Authority
• Validate why you should be able to generate a certificate for this domain
• Done over email, phone, DNS secret, or HTTP secret
• Wait until you receive your email and start using it

This process allows a client to check if the certificate/key pair is trusted. Most computer systems have a built-in Certificate Authority list with their keys, and can cryptographically check the validity of all certificate/key pairs. Even your browser has one built-in, and you can check it.

Because this process takes time, and/or costs money (CAs like Digicert, Namecheap, etc.) or requires a service on the public web (Lets Encrypt), then we are going to use a CA made by the teachers, and we will sign our own certificates.

Signing a certificate in the scoring server¶

For our own little Certificate Authority, we have set up a service named vault in our scoring system.

Vault is a secrets' engine, capable of securely storing secrets and generating them if necessary.

The main access point for vault is the web GUI - https://scoring.sa.cs.ut.ee:8200/ui/

For the authentication method, choose LDAP and log in with your University of Tartu central credentials.

You should see that a secrets engine named pki_int (PKI: Public Key Infrastructure, INT: Shorthand for intermediate) is available to you, and under that field, you can see a field for signing certificates under the domain sa.cs.ut.ee.

You can do this for every virtual host (there are 3 of them not including postfix). But you can also make a general name certificate bundle using *.<vm-name>.sa.cs.ut.ee for the Common name .

TLS in Apache (HTTPS)¶

Using certificate/key pair in Apache is fairly straightforward, but first, we have to generate our certificates.

The thing to remember is that the HTTPS uses port 443 instead of 80. You should also verify that your firewall rules reflect this.

TLS related site configuration directives can initially be found in the /etc/httpd/conf.d/ssl.conf file. We will use this as the template and create the configuration for the virtual hosts in their appropriate site configuration files.

You should familiarize yourself with the following Apache httpd configuration directives before moving to the next task

• SSLEngine
• SSLCertificateFile

Now, let's enable TLS with our web services.

TLS in Postfix¶

Last week we set up Postfix in a non-secure way. Anybody either in the client's network, or your personal VM's network, can eavesdrop on network traffic, and see any passwords and/or emails your email server sends or receives.

To remediate that, the solution is, again, using TLS. Enabling TLS means the following in Postfix:

smtpd_tls_security_level = may
smtpd_tls_cert_file=/etc/pki/tls/certs/postfix.pem
smtpd_tls_key_file=/etc/pki/tls/private/postfix.key
smtpd_tls_loglevel = 1
smtp_tls_loglevel = 1

Also, copy the certificate and key in place of the files we specified above, or sign a new one and copy that.

submission inet n       -       n       -       -       smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_tls_auth_only=yes
-o smtpd_reject_unlisted_recipient=no
-o smtpd_client_restrictions=$mua_client_restrictions
-o smtpd_helo_restrictions=$mua_helo_restrictions
-o smtpd_sender_restrictions=$mua_sender_restrictions
-o smtpd_recipient_restrictions=
-o smtpd_relay_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING

Now let's also enable secure submission over explicit TLS (SMTPS). We will use the same limitation policies as in the ''submission'' block

#smtps     inet  n       -       n       -       -       smtpd
#  -o syslog_name=postfix/smtps
#  -o smtpd_tls_wrappermode=yes
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_reject_unlisted_recipient=no
#  -o smtpd_client_restrictions=$mua_client_restrictions
#  -o smtpd_helo_restrictions=$mua_helo_restrictions
#  -o smtpd_sender_restrictions=$mua_sender_restrictions
#  -o smtpd_recipient_restrictions=
#  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING

TLS in Dovecot¶

Encrypting the traffic of the mail server itself is useless if the authentication credentials can be still seen by malicious people when logging into the mail server.

This is why we also need to encrypt traffic in Dovecot.

Self-signed certificates in a nutshell

Source for the image. Published on 11.01.2017 by E.William in The Barbed Wire.

Wireshark¶

This part is not mandatory, but it will help you to understand why we were doing what we were doing.

We will try to see if we can sniff some traffic.

First, go install yourself a tool called wireshark. (To your personal computer)

Once you have it installed, start it up with the highest permissions in your machine (Administrator in Windows, root in Linux and Mac).

You should get a window like this:

From there, you need to choose the proper interface. This depends on which interface your University VPN tunnel is working. If you hit the correct interface and double-click it, you should be getting a lot of traffic on the screen. If not, you're using the wrong interface.

Then, instead of the "Apply a display filter" line, write the following: ip.dst == <your_vm_ip> and (http or tls) And press enter.

After having done that, go and access the web pages on your machine. Use both http:// and https:// pages. You should be getting traffic on Wireshark.

After having done that, go and click on the traffic lines. See how different is TLS and HTTP information. With HTTP, you can see all the information that was exchanged. With TLS you cannot.

Just HTTP traffic:

Versus TLS traffic:

You can also try it with other pages on the world wide web, just remove the ip.dst filter.

Ansible and TLS¶

Putting the whole lab into Ansible is not something that would result in an idempotent playbook. So we will list the things that can be automated in an idempotent way, but some parts of the labs will require manual intervention by the user. The following suggestions and steps are just guidelines, if you think you can do better, feel free to do so.

Just because it is reasonable to do some bits manually doesn't mean you can't still use the playbook even if manual intervention is expected in the middle of the playbook. Read about the pause module from ansible. This allows you to stop your playbook execution, do things manually on the host in the meantime and then continue executing the playbook by simply pressing Enter in the terminal. This pause module is an option for issuing the openssl commands from the lab manual.

Keep your playbook safe¶

As per usual always push your playbook to the course's Gitlab.