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.

3 Answers 3


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).

  • Is the network admin able to decrypt the encrypted communication through the firewall if the network admin has obtained the private key of the web server?
    – IanCool
    Apr 28, 2016 at 5:15
  • Yes, that's logical. If you own the private key, you are able to decrypt communication encrypted with the corresponding public key.
    – techraf
    Apr 28, 2016 at 5:17
  • 2
    @IanCool: the last question is a completely different topic. And no, it is not safe to use just some random proxy server you found in a list on the internet. Public proxy servers are found to inject ads and malware into the trafffic - that's how they make money. Apr 28, 2016 at 5:30
  • 1
    With HTTPS as long as you verify the server's certificate in your browser you can be sure no third party is able to view your communication. That includes any public proxy. However if the server or a certificate authority which issued its certificate was compromised or an additional trusted certificate was added to your device, then the communication might be intercepted.
    – techraf
    Apr 28, 2016 at 5:33
  • 1
    Please mind that this is not a discussion forum. The link to the proxies had nothing to do with your original question.
    – techraf
    Apr 28, 2016 at 5:45

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.


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.

  • 1
    In TLS 1.3, now becoming fairly common (though it didn't exist in 2016 when the Q was asked), static-RSA keyexchange no longer exists and the certificates are encrypted. SNI still isn't by default, although there is an optional and not commonly used extension to do so. Also, any tampering with the handshake, including version or keyexchange or certificates, is detected by the Finished exchange and the connection aborted (all versions back to SSLv3). Jul 23, 2020 at 0:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .