Layer 7 Firewalls and SSL

[Silver-0-surfer]

Hi,

So I'm trying to get my head around this.

I get layer 7 (DPI) but my question is, how are they ( juniper, smoothwall, etc) able to do this on SSL sites.

I mean, isn't the entire point of SSL NOT for a firewall to inspect the traffic ( as its heavily ) encrypted.

Does anyone actually know how they can do it ( and they claim they can! ) and then obviously the follow up question, is it legal? To intercept SSL traffic (bank sites, etc). Surely if this is now "a thing" whats the point of SSL?

 

[Sinbad]

Hi,

So I'm trying to get my head around this.

I get layer 7 (DPI) but my question is, how are they ( juniper, smoothwall, etc) able to do this on SSL sites.

I mean, isn't the entire point of SSL NOT for a firewall to inspect the traffic ( as its heavily ) encrypted.

Does anyone actually know how they can do it ( and they claim they can! ) and then obviously the follow up question, is it legal? To intercept SSL traffic (bank sites, etc). Surely if this is now "a thing" whats the point of SSL?

They decrypt, examine and re-encrypt. Basically, permanent man in the middle "attack". The point of SSL is that the organisation that is running said device probably also controls the workstations behind it, and can load the bluecoat's signing key as a trusted key. Anything happening on their equipment is open to their scrutiny anyway.
If it was an "untrusted" device doing the man in the middle, you'd get certificate warnings. Our bluecoats will not allow you to surf to an SSL secured site that does not have a proper valid cert, so you're protected from "other" man-in-the-middle or spoofing attacks.

 

[Silver-0-surfer]

They decrypt, examine and re-encrypt. Basically, permanent man in the middle "attack". The point of SSL is that the organisation that is running said device probably also controls the workstations behind it, and can load the bluecoat's signing key as a trusted key. Anything happening on their equipment is open to their scrutiny anyway.
If it was an "untrusted" device doing the man in the middle, you'd get certificate warnings. Our bluecoats will not allow you to surf to an SSL secured site that does not have a proper valid cert, so you're protected from "other" man-in-the-middle or spoofing attacks.

OK. so you say 'If it was an "untrusted" device doing the man in the middle, you'd get certificate warnings.', what determines the trusted vs. untrusted? I have used squid proxy and sslbump to do content injection into SSL sites and, ofcourse, users got warnings about the certificate I loaded onto squid (as it was self signed, etc) - This I'm not contesting.

What is getting my puzzled, is *how* they are able to decrypt and re-encrypt an SSL site, isn't that what we all rely on, the safety of PKI? (and surly that would require massive resources, encrypting + decrypting + L7 for every packet)

EDIT: And just for clarity, they claim that this works without the end user having to trust any 3rd party CA's.

 

[Sinbad]

OK. so you say 'If it was an "untrusted" device doing the man in the middle, you'd get certificate warnings.', what determines the trusted vs. untrusted? I have used squid proxy and sslbump to do content injection into SSL sites and, ofcourse, users got warnings about the certificate I loaded onto squid (as it was self signed, etc) - This I'm not contesting.

What is getting my puzzled, is *how* they are able to decrypt and re-encrypt an SSL site, isn't that what we all rely on, the safety of PKI? (and surly that would require massive resources, encrypting + decrypting + L7 for every packet)

They decrypt it as if they were the SSL client. They then serve the content to your browser after re-encrypting it. Basically acting as a proxy server.

trusted vs untrusted - if it's a device my company manages, it's trusted. Its signing and encryption certificates are loaded as trusted certs in the keystores of the PCs it's protecting, so they don't raise warnings about invalid certs. A device out there on the internet that's not trusted, wouldn't have its certs in my keystore - so I'd get warnings.

 

[Silver-0-surfer]

They decrypt it as if they were the SSL client. They then serve the content to your browser after re-encrypting it. Basically acting as a proxy server.

For sure, this I get.

trusted vs untrusted - if it's a device my company manages, it's trusted. Its signing and encryption certificates are loaded as trusted certs in the keystores of the PCs it's protecting, so they don't raise warnings about invalid certs. A device out there on the internet that's not trusted, wouldn't have its certs in my keystore - so I'd get warnings.

cool, so what you are saying is, there is no "device" (software) that ,lets say an ISP (who's private ROOT CA is not trusted by me), can be put down between me and the internet and that can intercept my SSL traffic?

 

[Sinbad]

For sure, this I get.




cool, so what you are saying is, there is no "device" (software) that ,lets say an ISP (who's private ROOT CA is not trusted by me), can be put down between me and the internet and that can intercept my SSL traffic?

Not that I'm aware of. Maybe the NSA has something, but I doubt your average ISP does.

 

[Silver-0-surfer]

Not that I'm aware of. Maybe the NSA has something, but I doubt your average ISP does.

haha

OK, thanks man.

Last question if you have time.

How can anyone decrypt the SSL traffic in any event. I mean, my browser establishes an SSL connection with google, I get googles Public key and use that to encrypt the traffic, AFAIK you require the Private Key to decypt it? So unless, like with Squid & SSLBump, it actually stops the SSL handshake from happening with google (in this example) and forces it to happen with our "device"?

 

[Sinbad]

haha

OK, thanks man.

Last question if you have time.

How can anyone decrypt the SSL traffic in any event. I mean, my browser establishes an SSL connection with google, I get googles Public key and use that to encrypt the traffic, AFAIK you require the Private Key to decypt it? So unless, like with Squid & SSLBump, it actually stops the SSL handshake from happening with google (in this example) and forces it to happen with our "device"?

Your browser establishes an SSL connection with the proxy/firewall... Which then establishes the connection to google. It has all the keys right from the beginning of the transaction.

 

[Silver-0-surfer]

Your browser establishes an SSL connection with the proxy/firewall... Which then establishes the connection to google. It has all the keys right from the beginning of the transaction.

Nice.

Thanks for the clarity