Can firewalls decrypt SSL packets?

Question

I was wondering if the firewall has the ability to decrypt the SSL traffic.

If so, the network admin is able to read the data in clear text at transit.

Answer 1

SSL/TLS is a protocol providing an end-to-end encrypted communication between two parties each having one of the keys in private/public key pair. Typically a browser and a web server.

In normal circumstances any device between the two endpoints cannot decrypt the communication. That includes firewalls.

It is however possible (and used in organizations) to use a proxy server that decrypts and re-encrypts communication thus allowing interception and decryption (for example for monitoring and filtering). It does however require adding an additional certificate to a trusted certificate store on a client machine (either automatically through a software management system or manually by users).

Answer 2

As answered by @techraf, the re-encryption step from the proxy/firewall requires you to install an additional certificate (public key to match the private one the proxy has).

In effect, it’s a MITM attack, but one you agreed to.

The browser “trusts” the traffic, but the certificate chain is almost certainly different to one that you would see without the filter in place, since the signing chain now references the proxy/firewall signing certificate chain, not the one used at the traffic source.

You should be able to determine the traffic has been inspected, but the client is unlikely to be able to detect this without additional help. If you have an alternative route to the same site you might be able to request the original certificates directly and compare the cert chains.

Even if the signing chain is the same the fingerprint would be different.

Were someone to gain access to one of the private keys of a public certificate you already trust, you won’t need to install the extra cert & would find it quite hard to spot this. A fact probably not lost on enforcement agencies the world over. The only difference at the endpoint is (potentially) which signing & root certs were used to reseal the traffic.

Note that in the case of a firewall, no “proxy” configuration is involved, it can be done transparently.

Answer 3

The first few packets in the TLS 1.2 handshake are NOT encrypted. These include:

• Client Hello (I want to talk to server X with one of these cipher suites...)
• Server Hello (Okay, let's use cipher suite XYZ)
• Certificate (Here's my Server Cert for you to authenticate me)
• Certificate Request (Send me a Client Cert, I trust these roots...)
• Certificate (Here's my Client Cert)

After that the packets are encrypted. But Firewalls can and do modify those packets, they can swap out the certificates or force certain cipher suites.

A server-side firewall can be configured with the target server's private key cert, which can allow it to then decrypt the entire TLS session. Provided RSA is used for key exchange. If Diffie-Hellman is used for key exchange, then decryption isn't possible. But the firewall can force only cipher suites that use RSA (by modifying the Client Hello packet) if the client supports any cipher suites that use RSA.