How does SSL inbound decryption work exactly?

[cryptochrome]

I am not looking for a guide on how to configure it, there are plenty. What I want to know is how SSL inbound decryption works from an architectural point of view. In the docs it says that once you loaded the webserver's certificate onto the PAN device and enable inbound decryption, the traffic between client and server remains untouched. How is this done? Is the PAN working like a reverse proxy, e.g. the client connection is actually terminated on the PAN firewall and not the webserver behind it?

[hshah]

Hello Cryptochrome,

Its very intelligent question.

Topology:

Server-------PAN------Internet----Client

Digital certificate exported from Server is Imported on PAN, which means PAN and server have same certificate.

Client generate connection with Server, now PAN can intercept each and every packet. PAN has digital certificate of Servers, so it can read everything which server can.

Let me know if you need more information on this.

[mikand · Accepted solution]

Isnt Diffie-Hellman supposed to block such eavesdropping even if the attacker has the private key of the server?

The inbound decryption is like if you take a tcpdump of the traffic into a pcap file and load that into wireshark while you give the private key to the wireshark aswell. Unless DH is being used the wireshark will be able to decrypt the traffic. Same goes with PA which then can apply IPS filtering, logging etc on the decrypted traffic and if something bad is found it can block the session.

As already mentioned the client will have its ssl session straight to the server (and by that also be able to use client certs etc) - compared to when ssl-proxy is being used in PA which will have one ssl session between client and PA and another ssl session between PA and server (ssl-proxy wont work with client certs).

[Gregoux]

in fact between client and server only one session key is used.

and the private key have yo be present on the firewall that allow it to decrypt packets on the flow and the firewall decide to forward packet base on security profile that authorise the traffic

no decryption and reencryption on the fly but only decryption!

[cryptochrome]

Thanks all. Makes sense. Interesting point about Diffie-Hellman though!

[mikand]

Its often said that when using Diffie-Hellman for the sessionkey exchange the attacker must have access to the RAM contents in order to break that (well sort of 🙂

Anyone with a bit more knowledge of DH which could confirm my assumption that ssl inbound decryption wont work if the server uses DH?

[Gregoux]

you right

A DH key exchange is by design resistant to eavesdropping, although can be susceptible to a man-in-the-middle attack unless both parties identify themselves with certificates. It’s also, as we’ve seen, not universally supported by common SSL clients. But at least it rules out the possibility of some wiseguy with Wireshark sticking his fins where they’re not wanted!

but When you create your RSA key you need to precise the cipher that use the DH and it not used as default.

[Jia]

From -

No decrypt where diffie hellman is used in the key establishment, so I think you are right.