top of page

SSL Interception. Basics Concepts.

What is SSL Inspection?

SSL (Secure Sockets Layer) is a security protocol that encrypts data to help keep information secure while on the internet. SSL is no longer supported since 30 June 2018 and only TLS (Transport Layer Security) protocol is recommended but, regardless the protocol, the name has been kept as SSL intercept by common use.

SSL Intercept is the process of intercepting SSL/TLS encrypted internet communication between the client and server. Interception can be executed between the sender and the receiver and viceversa (receiver to sender)—it’s the same technique used in man-in-the-middle (MiTM) attacks, without the consent of both entities.

It is used not only to intercept HTTPS traffic, but SMTPS, POP3S, IMAPS and FTPS too.

We can diferenciate two ways of SSL Interception:

[if !supportLists]

  • Inbound (Protecting SSL Server):

This is intended for traffic inbound to an internal server or device. We must import the server certificate onto the Firewall in order to impersonate as the server from client point of view. This way is typically used on inbound policies to protect servers available externally through Virtual (public) IPs

  • Outbound (SSL Forward Proxy):

This is intended to proxy outbound SSL connections in a multiple clients to multiple servers environment. For the site the user wishes to visit, the firewall intercepts outbound SSL requests and generates a certificate in real time.

To achieve this, Firewall have to use a CA certificate to decrypt traffic properly by generating SSL certificates on the fly. In case you use a recogniced CA certificate, there is no problems, but in case you use a self-signed CA certificate, the public CA Certificate must be exported from the firewall, then installed as a Trusted Root CA on each machine’s browser to avoid Untrusted Certificate error messages inside your browser. Normally, network administrators use GPO to push this certificate to each workstation.

How does it work?

As I told before, it Works like a man-in-the-middle (MiTM) attack, in fact, it is, so SSL Interception is performed on a network device located between the client and server such a Firewall, Web Secure Gateway or ADCs (ssl offloading). I will use a Firewall from now on…

Here’s an overview of the SSL Inspection process

  1. First, a client iniciate an encrypted (HTTPS, SMTPS, POP3S, IMAPS or FTPS) connection to a server.

  2. The Firewall intercepts the traffic coming and decrypts TLS sessions between clients and servers.

  3. Once the traffic has been decrypted, the Firewall inspects the content through antivirus scanning, web filtering, etc.

  4. Then the interceptor encrypts the traffic and forwards it to the destination server.

Summariznig we can concluse that Firewall breaks connection as it acts as server to the client and acts as client to the destination server, so it manages two different TLS sessions (but it manage them as it was only one session).

Why you should use SSL interception?

It is so simple, using encryption, we keep our private data safe from other people, apps, organization, etc. However, these benefits can turn against us, as there are several risks associated using SSL/TLS encryption, since encrypted traffic can be used to get around your normal defenses…

Trying to be clear, imagine you are going to download a file over HTTPS webpage… as it is encrypted, your security devices cannot see if the file contains or not a virus or something like that…

To protect your network from these threats, SSL inspection is mandatory. However, using SSL inspection can reduce the overall performance of your Firewall because it need to use too many resources in order to perform decrypt/re-encrypt tasks..

Briefing, you have to choose to improve your security sacrificing some performance, but weighing up the pros and cons, I would always recommend to perform SSL interception.

How to deploy SSL interception?

Now we have clear, what is, how does it works and why we should use it, let´s go to learn some tips to keep in mind when we want to deploy SSL interception.

As told you before, SSL inspection impacts on the Firewall performance so we must be careful at that time.

There are three main things to do:

  • First of all, we have to known our traffic, I mean, it will be very dificult to deploy SSL interception in an environment we does not know, in orther words, if we known our traffic, we could be selective with what kinds of traffic we want to intercept or not…

  • Then, we have to deploy it gradually, with the granularity / flexibility offered by firewall policy rules… is not recommended to deploy all toguether because of firewall performance decrease.

  • Finally, be aware of local legal and regulatory differences, and how they affect which traffic you can intercept/log and where you can store logs… For example there are law restrictions with intercepting traffic from finance and health web categories…

Out of these main suggestions, you can take a look of the below too:

  • Exclude applications that may break upon decryption.

  • Enforce certificate status. (drop expired or untrusted).

  • Enforce cipher suites (e.g. AES as 3DES is retired on July 19, 2018).

  • Enforce protocol versión (e.g. TLS 1.2 only).

  • Integrate with hardware security modules (see HSM).

  • Allow users to opt out of SSL decryption (alert users and let them choose).

  • Decrypt SSH (similar threat prevention for SSH protocol).

Highlighted entries
Recent entries
Archive
Follow me
  • Icono social LinkedIn
bottom of page