HTTP versus HTTPS during MiTM

Today I will talk about the difference between the HTTP and HTTPS network flow and how HTTPS works in background, introducing cryptography concepts.

Table of contents:

  1. Introduction
  2. Topology
  3. Attack, HTTP inspection
  4. Remediation
  5. HTTPS inspection
  6. TLS explanation
  7. Conclusion

Introduction

The Hypertext Transfer Protocol (HTTP) is an application protocol for distributed, collaborative, and hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web.

The most popular way of establishing an encrypted HTTP connection is HTTPS.[27] Two other methods for establishing an encrypted HTTP connection also exist: Secure Hypertext Transfer Protocol, and using the HTTP/1.1 Upgrade header to specify an upgrade to TLS. Browser support for these two is, however, nearly non-existent.

The purpose is to analyze of flow in HTTP and another one in HTTPS and compare difference.

Topology

 

Sans titre.png

Attack, HTTP inspection

The hacker has compromised the employee computer ( with ARP poisoning, LAN MiTM).

All the traffic to/from the employee (192.168.0.2) is intercepted by the hacker (192.168.0.1), modified or not, and then forward to the router/the employee.

Sans titre.png

The legitimate employee authenticates on web page without encryption:

Image2.png

Here is what the hacker see on its network analyzer when the hacker is tapping the network for HTTP protocol:

Sans titre.png

The credentials are forwarding to the server in clear on the network and the hacker can use the login:password retrieved : identity usurpation !

To remind with the OSI model, a compromise on the network layer compromised all the layers above:

Sans titre.png

So how to have the communication safe even if the computer is compromised and a MiTM occurred ?

Remediation

I will implement TLS on the server.

I create a special virtualhost file dedicated to my DVWA web application from the 000-default.conf:

osboxes@osboxes:/etc/apache2/sites-available$ ls
000-default.conf default-ssl.conf dvwa.com.conf

Here is dvwa.com.conf content:

<VirtualHost *:80>
 ServerName dvwa.com
 ServerAlias www.dvwa.com
 ServerAdmin webmaster@localhost DocumentRoot /var/www/html/
 ErrorLog ${APACHE_LOG_DIR}/error.log
 CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

I activate the new configuration:

osboxes@osboxes:/etc/apache2/sites-available$ sudo a2ensite dvwa.com.conf
Enabling site dvwa.com.
To activate the new configuration, you need to run:
service apache2 reload
osboxes@osboxes:/etc/apache2/sites-available$ sudo service apache2 reload
* Reloading web server apache2

My virtualhost dedicated to my web application is activated.
Now I activate the SSL mod :

osboxes@osboxes:~$ sudo a2enmod ssl
[sudo] password for osboxes:
Considering dependency setenvif for ssl:
Module setenvif already enabled
Considering dependency mime for ssl:
Module mime already enabled
Considering dependency socache_shmcb for ssl:
Module socache_shmcb already enabled
Module ssl already enabled

I restart the web service:

osboxes@osboxes:/etc/apache2/sites-available$ sudo service apache2 restart
* Restarting web server apache2 [ OK ]

Let’s start off by creating a subdirectory within Apache’s configuration hierarchy to place the certificate files that we will be making:

osboxes@osboxes:/etc/apache2/sites-available$ sudo mkdir /etc/apache2/ssl

Now that we have a location to place our key and certificate, we can create them both in one step by typing:

osboxes@osboxes:/etc/apache2/sites-available$ sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/apache2/ssl/apache.key -out /etc/apache2/ssl/apache.crt
Generating a 2048 bit RSA private key
.............+++
................+++
writing new private key to '/etc/apache2/ssl/apache.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Ille-et-Vilaine
Locality Name (eg, city) []:Rennes
Organization Name (eg, company) [Internet Widgits Pty Ltd]:DVWA
Organizational Unit Name (eg, section) []:security
Common Name (e.g. server FQDN or YOUR name) []:dvwa.com
Email Address []:

Sans titre.png

The private key looks like this:

osboxes@osboxes:/etc/apache2/sites-available$ cat /etc/apache2/ssl/apache.key
Sans titre.png

The certificate:

osboxes@osboxes:/etc/apache2/sites-available$ cat /etc/apache2/ssl/apache.crt
Sans titre.png

Instead of basing our configuration file off of the 000-default.conf file in the sites-available subdirectory, we’re going to base this configuration on the default-ssl.conf file that contains some default SSL configuration:

osboxes@osboxes:/etc/apache2/sites-available$ cat default-ssl.conf
<IfModule mod_ssl.c>
 <VirtualHost _default_:443>
  ServerAdmin webmaster@localhost
  ServerName dvwa.com
  ServerAlias www.dvwa.com
  DocumentRoot /var/www/html
  ErrorLog ${APACHE_LOG_DIR}/error.log
  CustomLog ${APACHE_LOG_DIR}/access.log combined
  SSLEngine on
  SSLCertificateFile /etc/apache2/ssl/apache.crt
  SSLCertificateKeyFile /etc/apache2/ssl/apache.key
  <FilesMatch "\.(cgi|shtml|phtml|php)$">
   SSLOptions +StdEnvVars
  </FilesMatch>
  <Directory /usr/lib/cgi-bin>
   SSLOptions +StdEnvVars
  </Directory>
  BrowserMatch "MSIE [2-6]" \
  nokeepalive ssl-unclean-shutdown \
  downgrade-1.0 force-response-1.0
  # MSIE 7 and newer should be able to use keepalive
  BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
 </VirtualHost>
</IfModule>

I enable the SSL-virtual host:

osboxes@osboxes:/etc/apache2/sites-available$ sudo a2ensite default-ssl.conf
[sudo] password for osboxes:
Enabling site default-ssl.
To activate the new configuration, you need to run:
service apache2 reload
osboxes@osboxes:/etc/apache2/sites-available$ sudo service apache2 reload
* Reloading web server apache2

When I reach my website over the 443 port, I get a warning message :

Sans titre.png

Indeed, because the certificate is self-signed, it is not trusted. I accept it.
If I want to have details about the certificate:

Sans titre.png

HTTPS inspection

The legitimate employee authenticates on the same web page with encryption this time:

Image1.png

The hacker is still in MiTM:

Image3.png

He could suspect a web activity regarding the port reached, 443 (famous for HTTPS):

Image4.png

But he don’t have a clue about what the parameters (credentials) forwarded toward the server !

TLS explanation

Now I will explain each packet part in the TLS handshake and encryption. First, best to know is that the exchange above was tape during two main steps:

Client “Client Hello” packet

Client forwards the maximum TSL version it supports, as well as the cipher suites it can handle with, by top down preference, and a 32 bits random value.

tmp.png

The client will send a list of all the SSL/TLS protocol versions it supports, with the preferred one being first on the list. The preferred one is usually, and should be, the latest available version.

tmp.png

Cipher suites are combination of cryptographic algorithms which are used to define the overall security of the connection to be established. Typically, each cipher suite contains one cryptographic algorithm for each of the following: Key Exchange, Authentication, Bulk (data) Encryption and Message Authentication.

tmp.png

A 32-byte random data of which 4 bytes represent the client’s current datetime (in epoch format) and the remaining 28 bytes, a randomly generated number. The Client’s random and Server’s random will later be used to generate the key which the data will be encrypted with.

Server “Server Hello” packet

tmp.png

The packet is from the server and tells the client the TLS version they will use, the cipher suite and the random value. The server will (not blindly) select the Client’s preferred version of SSL/TLS protocol.

tmp.png

If supported, the server will agree on the Client’s preferred cipher suite.

tmp.png

32 bytes of random data, out of which 4 bytes represent the server’s current datetime (in epoch format), and the rest 28 bytes is a randomly generated number will be sent to the client. The Server’s random and Client’s random will later on be used to generate the key with which the data will be encrypted.

Server “Certificate” packet

From the server toward the client, consist in the server certificate:

tmp.png

Here only one certificate because I implement a self-signed. Otherwise, they would the one from the CA as well:

tmp.png

tmp.png

It also contains the server public key.

Server “Server key exchange” packet

tmp.png

Additional message from the server to the client to indicate it the public key the client will use to cipher information for the session key.

tmp.png

Server “Server Hello done” packet

The server indicates it sends all information to the client:

tmp.png

Client “Client key exchange” packet

tmp.png

The client generates a pre-master key. It is generated from a random number. The random nonce is then ciphered using the server public key from the server certificate which contains the public key:

tmp.png

This means that only the server can decrypt the message since asymmetric encryption is being used for the pre-master secret exchange.

preMasterSecret = random()

Client “Change cypher-spec” packet

The Change Cipher Spec protocol is used to change the encryption being used by the client and server. The client encrypted the pre-master key using the server public key.

tmp.png

encrypt(certicate.publicKey, preMasterSecret)

Client “Encrypted handshake message” packet

This is the first encrypted message sent from the client to the server. It is the pre-master secret key that has been encrypted using the server public key.

tmp.png

Server “Change cypher spec” packet

The server tells the client to change the ciphering mode, going the the symetric way.
Indeed, after the server receives the pre-master secret key, it uses its private key to decrypt it.
Now the server will compute the master-secret key based on the random values exchanged earlier (pre-master key, ClientRandom and ServerRandom).

tmp.png

Server “Encrypted handshake message” packet

The server responds to the client and confirms to it that the server can handle the TLS encrypted session.

tmp.png

Client application data

This is the first packet out of the handshake protocol.
Here we know that originally, it was an HTTP packet that has been ciphered using SSL (TSL) protocol.

And it goes on for each request, a new shared master key is generated from the concatenation of the two 32 bits randomly generated from the client and server.

Then ciphered using server public key.

tmp.png

Conclusion

The concept introduced here is the “in-depth-defense”.

Sans titre.png

It means that even if you got a layer compromised, by hardening a higher layer, you can protect the sensitive information that pass through the network.

Futhermore, pay attention to these additional security mesures:

-Always set “secure cookies” on the server for making them being transmitted only over encrypted HTTP connections (SSL/TLS) [Server]

-Be aware if your Certificate Authority has been compromised by having its private keys stealed [Security watch]

If you have any question, I will be glad to answer you back ????

Also have my twitter account, gr3g0v1tch !

 

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *