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.

score 17 · Accepted Answer · edited Mar 17 '17 at 13:14

17

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

edited Mar 17 '17 at 13:14

Community

1

answered Apr 28 '16 at 05:09

techraf

9,141
11
44
62

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 '16 at 05: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 '16 at 05:17
Speaking of proxy server, is it safe to use public proxy server. Reason being, I configured my iphone to connect to public china proxy server for watching the blocked live streaming that hosted in china. – IanCool Apr 28 '16 at 05:24
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. – Steffen Ullrich Apr 28 '16 at 05: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 '16 at 05:33
With government-controlled proxy it would however be better to assume your communication relying on PKI is not fully private. – techraf Apr 28 '16 at 05:38
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 '16 at 05:45

score 2 · Answer 2 · edited Apr 06 '21 at 10:37

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.

JD Brennan · Answer 3 · 2020-12-16T20:15:18.060

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.

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). — dave_thompson_085, Jul 23 '20 at 00:46

Can firewalls decrypt SSL packets?

3 Answers3