Https inspection

Hi All,

Can any one explain how https inspection works, i understand that firewall acts as a client and establishes tunnel with server but how firewall verifies the server's certificate. Which key is used by firewall to decrypt traffic???

Regards,
Bharath

Find more posts tagged with

Comments

JollyFrogs

Hi bharath,

The firewall generates its own certificate, and this certificate is loaded on the client browser as a trusted certificate authority. The firewall can then intercept and decrypt the SSL request - to the client, the firewall IS the destination server. The firewall then uses the decrypted information and creates a new SSL connection (encrypted) using the firewall's own private certificate to retrieve the SSL content. To the real SSL server, the firewall is the real client; the SSL server does not know that it's talking to another client because it isn't - it's simply talking to the host that it's supposed to be talking to: the firewall. The firewall then receives and decrypts this content and forwards it (re-encrypted) to the client. Again, the client believes it's talking to the end-server and not the firewall. If the user were to thoroughly check the certificate chain in their browser (click the little "lock" icon), they would notice that the certificate was signed by the firewall's (or company certification authority) signing certificate authority (which was imported into the browser earlier as a trusted signing authority), and not by a publicly trusted certification authority - this is usually a dead giveaway that HTTPS is being intercepted (at work for instance).

636-555-3226

I'll add from an "advanced" security point of view that intercepting https encryption helps with novice attacks. once you get past the 101-script kiddies using off the shelf malware you're into custom encryption land, and your man-in-the-middle SSL interceptor doesn't know what to do with it, so you either allow it to pass uninspected or you terminate the connection at the gateway and say tough love to the end-user (most often) or hacker (on occasion). legit software that doesn't properly implement SSL encryption (b/c of unaware programmers just not knowing how to implement it) can be flagged as custom encryption since your gateway gets confused by its wonkiness.

also keep in mind bad that smart guys know that many companies decrypt SSL connections, so even if they don't know how to create or adopt their own custom encryption mechanism they can try to exfiltrate data through categories of websites that many companies allow to pass unencrypted, such as bank, email, health, etc. many companies don't inspect those types of sites for privacy/regulatory reasons, so an adversary can, for example, email all of his stolen data to gmail.

YFZblu

636-555-3226 wrote: »

once you get past the 101-script kiddies using off the shelf malware you're into custom encryption land, and your man-in-the-middle SSL interceptor doesn't know what to do with it, so you either allow it to pass uninspected or you terminate the connection at the gateway and say tough love to the end-user (most often) or hacker (on occasion).

Generally speaking, custom encryption is normally happening on the data payload itself, not at the protocol layer. What's more likely is that an attacker might encrypt command-and-control communication, but still send it out over HTTP. Even if an attacker does utilize TLS, it would still function as TLS does - if decrypted, the TLS communication would reveal the encrypted C2 instructions or data, and has no effect on how inspection takes place at the protocol layer.

I think what you're referring to, attempting to inspect the data payload, a product would be looking to apply signatures to identify encryption protocols, and perform entropy analysis in an effort to possibly identify unknown or custom encryption. I have seen DLP solutions try this with web traffic that has already had its protocol-level encryption stripped, but haven't seen anyone try to inspect both protocol-layer and application data with a single device. I feel like, for the vast majority of organizations, this runs the risk of adding a lot of latency, and potentially breaking normal communication. As it stands, most who manage in-line devices are already blamed for every computer issue known to man. Of course, it is possible to perform these tasks out-of-band, but that isn't what the OP is referring to.

bharath917

Thanks for the your response. As per checkpoint's website

In outbound HTTPS inspection, when a client in the organization initiates an HTTPS connection to a secure site, the Security Gateway:

Intercepts the request.
Establishes a secure connection to the requested web site and validates the site server certificate.
Creates a new SSL certificate for the communication between the Security Gateway and the client, sends the client the new certificate and continues the SSL negotiation with it.
Using the two SSL connections:
- It decrypts the encrypted data from the client.
- Inspects the clear text content for all blades set in the Policy.
- Encrypts the data again to keep client privacy as the data travels to the destination web server resource.

I want to know how firewall verifies Certificate of the Server, because firewall does not have trusted root Certificates.Kindly let me know if there is any book which has more details about this...

JollyFrogs

bharath917 wrote: »

... firewall does not have trusted root Certificates.

This assumption is incorrect. Every host that verifies HTTPS websites requires a root certificate store of all the major public vendors. This includes Checkpoint firewalls and any other firewall that inspects HTTPS. (the "collection" of public root certificate authorities is often referred to as the "CA bundle". Every browser has one too by default (this is where Firefox makes a lot of their money for instance; they charge these root certificate authority companies lots of money for the privilege to be loaded into the default browser store).

Refer to this article which confirms the presence of the ca-bundle in Checkpoint:
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk64521
"An important part of the HTTPS Inspection support is the validation of the server's certificate. This validation requires validating the signing CA of the server certificates.
Security Gateway with enabled HTTPS Inspection has a built-in predefined list of trusted CAs, based on the Windows System stores. This list is updated by Microsoft Updates."

and an interesting story here:
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk65277

NotHackingYou

bharath917 wrote: »

I want to know how firewall verifies Certificate of the Server, because firewall does not have trusted root Certificates.Kindly let me know if there is any book which has more details about this...

In addition to above response by JollyFrogs, most modern MITM-capable devices will allow you to load root CAs not currently on the device.

bharath917

Thanks a lot, now i got to know that Firewall also has Trusted root Certificates.
I have few 2 more questions..

1. To encrypt the data firewall should generates the Session key, Firewall encrypts the session key using public key of Server and sends to server. This key is used for Encryption and Decryption of Data.

2. As per my understanding Client PC also should generate the session key for encryption and decryption, Does client generates same key as generated by Firewall?
Two tunnnels will establish once inspection is enabled, which keys are using to Encrypt/Decrypt the data in System end and in Firewall End...

NotHackingYou

It's easiest to consider that the firewall has two interfaces. One for egress traffic to/from the internet. One for ingress traffic to/from the client. Each should be a completely separate TCP and TLS session. Therefore, the keys from one side would not match the other.

PJ_Sneakers

There are basically two sessions. One between your PC and the firewall, and one between the firewall and the site you are visiting. They use different certificates. The one between your PC and the firewall will come from an internal CA. The one between the firewall and the website will use whichever CA the site uses.

OctalDump

[QUOTE=bharath917]I want to know how firewall verifies Certificate of the Server, because firewall does not have trusted root Certificates.Kindly let me know if there is any book which has more details about this...[/QUOTE]

CarlSaiyed wrote: »

In addition to above response by JollyFrogs, most modern MITM-capable devices will allow you to load root CAs not currently on the device.

I took bharath917's comment to mean, why would the computer trust the firewall device for an arbitrary website. Why would it not throw the error of "certificate mismatch" on the client device. My understanding is that it required the client device to be configured, which is achievable in most enterprises where centralised management of clients is the norm. I suspect some similar effect could be achieved with DHCP and DNS.

bharath917

Hi All,

Finally i understood how deep inspection works..thanks for your valuable response.

I am testing this in lab,i am using Fortigate FW. It has Local and CA certificate. As per Fortigate website we can use either Fortigate local certificate or Open SSL certificate in End user Machines. Before that i need to install OpenSSL cert in Firewall.
Could you please clarifiy what is the adavantage of using OpenSSL Certificate.
Should i use OpenSSL or Fortigate cert in PCs?

Regards,
Bharath