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. Clicking on sa.cs.ut.ee will bring you to the form where you can request your certificates.

You can generate certificates for every virtual host (www, proxy, wordpress, mail) using <service-name>.<vm-name>.sa.cs.ut.ee in the Common Name field. You can also make a general name certificate bundle using *.<vm-name>.sa.cs.ut.ee for the Common name. This type of certificate is called a wildcard certificate, and it allows the certificate to secure multiple subdomains in a single domain. So a certificate for *.testing.ee could be used for www.testing.ee, wordpress.testing.ee, shop.testing.ee, etc.

In practice wildcard certs need to be used carefully. Their main issue is that if one service is compromised and your private key is exposed, all services using that certificate become vulnerable. For this course, using a wildcard certificate is okay, especially when adding certificates manually. Later, when you implement Ansible automation, managing individual certificates for each service will become significantly easier.

TLS in Apache (HTTPS)¶

Using certificate/key pair in Apache is fairly straightforward, but first, make sure you have generated a valid certificate.

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¶

Requesting a certificate from HashiCorp Vault¶

To talk with our HashiCorp Vault instance we are going to use an Ansible community collection called hashi_vault. Install it by running this command:

ansible-galaxy collection install community.hashi_vault

We are interested in the vault_pki_generate_certificate module, which allows us to communicate to a Vault instance and generate a new set of credentials from there. Here is an example on how to use it:

- name: Request a certificate from HashiCorp Vault PKI
  community.hashi_vault.vault_pki_generate_certificate:
    url: "https://scoring.sa.cs.ut.ee:8200"
    auth_method: "ldap"
    username: "{{ vault_ldap_username }}"
    password: "{{ vault_ldap_password }}"
    engine_mount_point: "pki_int"
    role_name: "sa.cs.ut.ee"
    common_name: "www.<vm-name>.sa.cs.ut.ee"
  register: vault_pki_response
  delegate_to: localhost
  become: false

ansible-vault encrypt_string --prompt

vault_ldap_password: !vault |
      $ANSIBLE_VAULT;1.1;AES256
      37653965313432646137383039396538306333353566626135343034386566393839396464646266
      3762386237356638353666663137623763623162613439320a303331613233353339666437333034
      63353937633938393038646237386535386239373039653061613261633636316130643231643366
      6639633730333966360a313961316561363732346131363863343736633633653839656663363034
      3464

Let's go over the vault_pki_generate_certificate module parameters:

This module has many more parameters, you can see them all in the official documentation. The parameters described above are all you need for this practical.

The example task has some keywords defined in addition to the module parameters:

Keep in mind that every rerun of this task will go and ask for new credentials even when they might not be needed (valid certificates/keys are already present). This makes it not truly idempotent, although with clever use of conditionals you can check if the certificate files exist and skip the task if necessary. As mentioned before, the credentials in this course are free.

Using the HashiCorp Vault PKI response¶

Now we know how to get the credentials from HashiCorp Vault, but we need to also figure out how to get this data into our remote host.

We used the register keyword to put the PKI response into a variable called vault_pki_response. Use the Ansible debug module to examine this variable and the data inside it or refer to the return values section of the certificate generation module.

After getting familiar with the structure of the data, try to use the task below to create your credential files on the remote host. Make sure you understand what this task does and what you need to write in place of the xxx. Pay attention to the way the CA chain is stored, here is a small tip for what you have to do.

- name: Populate certificate files with Vault PKI response
  ansible.builtin.copy:
    content: "{{ item.content }}"
    dest: "{{ item.path }}"
    mode: "{{ item.mode }}"
  with_items:
    - { path: '/etc/pki/tls/certs/www_server.crt', content: "{{ xxx }}", mode: '0644'}
    - { path: '/etc/pki/tls/certs/cacert.crt', content: "{{ xxx }}", mode: '0644'}
    - { path: '/etc/pki/tls/private/www_server.key', content: "{{ xxx }}", mode: '0600'}

Putting it all together¶

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.