How does MITM Work with Guardian and HTTPS traffic?

Article #: Product: Version:
# Guardian All


It's not very clear what happens when Guardian intercepts HTTPS traffic. This article aims to explain this.


The point of HTTPS websites is two-fold:

  • Authentication — You can be sure that the website you are "communicating" with is the true website.
  • Encryption — You can be sure that communication to the website is protected against eavesdropping. Similar to putting a wax seal on an envelope.

Let's continue with the wax seal and envelope analogy:

Communication between the browser and website is via wax sealed envelopes (encrypted TCP packets). In order to inspect the contents, and apply relevant filtering policies, Guardian needs to break the seal and open the envelope (decrypt the TCP packets and read the contents). It still needs to deliver the envelope to the website, but if an envelope with a broken seal (an unencrypted TCP packet) is delivered, the website will reject it.

Certificate Authorities (CAs) are used as a way of recognizing the wax seal. Envelopes arriving with a recognized seal are trusted.Since Guardian cannot copy the original seal, it has to ask connecting clients to trust its seals instead, hence why the HTTPS Interception page provides the ability to download and install the CA onto client devices.

Guardian provides the ability to decrypt and inspect HTTPS traffic, so that relevant filtering policies can be applied. This goes against the purpose of HTTPS websites, thus without a valid CA, the browser may interpret Guardian's actions as a MITM attack.


The following details the steps involved when Guardian (Smoothwall) decrypts and inspects HTTPS traffic:

  1. The Smoothwall intercepts the HTTPS TCP packets
  2. Is the site set to be decrypted and inspected. The options are:
    • Check the certificate validity
    • Decrypt and inspect
    • Do nothing
  3. If it is do nothing or check the certificate, the Smoothwall effectively joins the connection to the client to the connection to the website. This cuts the Smoothwall out of the loop as the site's real certificate is used to encrypt the client-server connection.
  4. If it is decrypt and inspect, then the Smoothwall needs to establish two full HTTPS connections:
    1. One to the website, using the their certificate — This allows Smoothwall to fetch content on behalf of the client.
    2. The second to the client.
  5. Since the Smoothwall does not know the website certificate's private key, that cannot be used to establish an HTTPS connection to the client.
  6. Instead, it uses the MITM Certificate Authority (CA) (that it does have the private key for) to create a certificate for the site. Because this "fake" certificate is made using the MITM CA, the MITM CA must first be trusted by any clients that Smoothwall is decrypting and inspecting traffic for.

  7. Having created a "fake" certificate, Smoothwall can establish the secure client connection, leaving the client thinking it is the site requested.
  8. By sitting in the middle, Smoothwall is able to see and manipulate the full contents of every packet sent by both the client and the website.
  9. Note: The above is relevant for transparent and non-transparent proxying. The only difference is that non-transparent configurations are "proxy-aware".

    Note: Even if you don't have any decrypt and inspect policies configured in Guardian, it should be noted that Smoothwall will still act as a MITM when a blockpage is required, or when using Guardian authentication policies that require a redirect, for example, to an SSL login page.


Last updated: Author: Contributions by:
7th July 2016 Dan Mckean-Tinker Samantha Nair