Encrypted web stream interception

To secure our internet traffic, we use multiple encryption protocols designed to add one or more security layers (privacy, authenticity,...) to existing protocols that do not natively include those. TLS (Transport Layer Security), developped by the IETF, is one of the most used, and is the evolution of SSL (Secure Socket Layer), which was developped by Netscape. TLS allows us for example to shop on the internet using our credit cards, using encrypted HTTPS web streams (TLS layer over HTTP).

1 Encrypted web stream principle

When a client consults a secured web page, the server hosting this website first displays its identity, by sending the client (our internet browser) an electronic certificate which indentifies it uniquely.

How can the client trust this certificate authenticating the server?

Just as a notary validates the authenticity of administrative acts, Certificate Authorities (CA) exist for digital transactions. Web browsers know theses CA by their certificates stored in certificate stores they manage (Firefox), or managed by the operating system (Chrome and IE on Windows).

When a browser connects to a secured web server, it receives its certificate, and checks if this certificate is signed by an authority present in the certificate store.

Two cases can then appear:

  • First case : the received certificate is authenticated.
  • green padlock
    Figure 1. Connection with a signed certificate.

    This padlock indicates that the consulted website certificate is signed (recognized) by a valid CA. The browser then initiates the encrypted connection with the server. We are now in one of those configurations :

    If you are in your home
    Figure 2.1. If you are in your home.

    If you are in a company.
    Figure 2.2. If you are in a company.

  • Second case : the received certificate is not signed by a known authority (unauthenticated certificate).
  • Connection uncertified by a certificate authority.
    Figure 3. Warning showing the certificate is unsigned on Firefox

    In this case, the browser asks the user whether or not to continue with the connection. The risk is that a person is intercepting the encrypted stream by presenting his own certificate. This person is now able to decrypt the entirety of the communication, this is known as a "Man in the Middle" (MitM) attack.

    2 Encrypted web stream interception

    In a MitM attack, the goal of the attacker is to intercept his victim's encrypted trafic. To do so, he can use two techniques (see Figure 3 and 4). Once the victim's web traffic has been retrieved, the attacker can directly read unencrypted protocols (FTP, HTTP, VOIP, ...). For encrypted streams, the attacker has to forge a false certificate to send to his victim, which will display an alert (Figure 3) on the victim's browser as soon as he accesses a website using HTTPS. Since certificates contain fields specific to each server (domain name, date, ...), the attacker has to be able to generate them dynamically according to his victim's browsing. Tools like "sslsplit" allow the automatisation of such a process.

    green padlock
    Figure 4. (left) Modifying ARP cache*. / (right) Inserting a hub into the local network.

    [*] - This technique, known as "cache poisoning", can be avoided by configuring correctly the network devices (switches, WiFi access points, ...)

    In a company, this method can be set up with a proxy (Figure 5).

    cadenas vert
    Figure 5. Example of a company network using an HTTPS inspector.

    3 Highlighting a Man in the Middle attack

    We can detect this kind of attack by comparing the certificate seen by the client with the actual certificate of the server. Normally, both certificates match, there is no difference between the two. But if the fingerprint of client's certificate is different from the server's, that means that the communication is decrypted by a third party.

    cadenas vert
    Figure 6. Sending of the certificate with or without proxy.

    We can see (Figure 6) that the certificate received by the client is the proxy's. The proxy starts by executing the request of the client, then it becomes the client of the website, and sends its responses to the client by pretending to be the web server.

    4 Detecting an interception

    CheckMyHTTPS works this way :

  • The client visits an HTTPS website.
  • The client requests the CheckMyHTTPS' test server certificate.
  • The client sends the fingerprint taken from this certificate.
  • The test server will compare its own fingerprint with the one sent by the client.
  • The addon will display the result using a padlock. (Green if both match : no interception; red if there is a mismatch : potential interception; yellow if the comparison is in progress).
  • Every internet user can know if the SSL/TLS stream between his browser and a secured website is intercepted, or even modified. For example, this addon will react if the antivirus Avast is installed on the user's computer, as this it installs its own certificate above the other recognized authorities to decrypt the SSL/TLS stream using a local proxy it manages. On a company network, an employee could be able to ask the director of information systems why he deemed necessary to set up an interception system. The employee will be aware that is "secured" traffic will be decrypted.

    cadenas vert
    Figure 7. CheckMyHTTPS explanation.

    Install the extension

    Addon Firefox

    If you do not want to get the extension, you can run a quick test by submitting an URL



    Advice : Why not test "https://checkmyhttps.net"?