PDA

View Full Version : HTTPS Inspection - Real world experience



DZelenak
2015-06-30, 16:55
I didn't know where else to post this, and this forum seems to cover everyone here :)

I'm looking to get some real world reports of people doing HTTPS inspection with Check Point gateways. Right now we're using AV, AB, and IPS. I wouldn't mind turning on Application Control either. We've got about 1K users behind a 4600 gateway, and we're a Google Apps shop - so pretty much everyone has some HTTPS going on at all times. I feel we're probably missing a lot of bot and AV traffic by not doing HTTPS inspection.

How has your experience been? What are the performance implications? Did you inform your user base that you're doing HTTPS inspection? Did you have issues with clients getting certificate errors?

msjouw
2015-06-30, 17:19
We run this for one of our bigger customers, they have a 4600 cluster for about 400 users, they are currently in the final testphase and as this is a lawyer firm, they did inform there users.
They were running Websense before, I can tell you we had and still have our fair share of failing sites. There are some newer encryption methods that will only be supported by R77.30 but there not so many sites using this yet.

You will need to make a number of rules to make sure thjat bypass is setup correctly, either based on source IP (servers getting updates), specific destination IP's and specific categories (ie. Financial).

Also add to that last one a new category called HTTPS-Decrypt-Bypass and then when you need to create a new application/site that needs HTTPS Decryption Bypass just set the category to that new app/site and your done.

DZelenak
2015-06-30, 17:57
We run this for one of our bigger customers, they have a 4600 cluster for about 400 users, they are currently in the final testphase and as this is a lawyer firm, they did inform there users.
They were running Websense before, I can tell you we had and still have our fair share of failing sites. There are some newer encryption methods that will only be supported by R77.30 but there not so many sites using this yet.

You will need to make a number of rules to make sure thjat bypass is setup correctly, either based on source IP (servers getting updates), specific destination IP's and specific categories (ie. Financial).

Also add to that last one a new category called HTTPS-Decrypt-Bypass and then when you need to create a new application/site that needs HTTPS Decryption Bypass just set the category to that new app/site and your done.


Nice. Thanks for the reply. Why did you move from Websense? We're currently a Websense customer as well, and our Websense rep wants us to test drive their solution as well. We run Websense Web Security spanning the VLAN that goes to the Check Point cluster. Websense catches a LOT of bot traffic based upon it's URL database alone. In fact, we're lucky to see a few hits a week on the Check Point solution with this in place. Someday I'm going to turn Websense's security categories off for a period and see how the Check Point fares.

Fortunately we're running R77.30 on all our boxes. Do you know if the new inspection is for the new QUIC protocol that Google is using?

msjouw
2015-06-30, 18:05
As I said we had and have a high number of problems with specific sites with Websense. The customers we have that use this product with HTTPS decryption are not happy with the number of issues we run into. We are not running them in network agent mode but real proxy mode, with Content gateway, some customers have multiple content gateways.
The protocol that was not supported before 77.30 was ecdhe with aes256

Cory Webb
2015-06-30, 22:31
I have customer using both flavors of Check Points HTTPS inspection, the full blown certificate based one and the 'lightweight' categorization of https sites options. Both work pretty good, I'd guess the categorization is about 85-90% accurate vs the full one. There is some performance impact of course due to the extra load placed on the gw to now inspect SSL, but we have environment running more users behind similar appliances and it is unnoticeable by the end users

aweldon
2015-07-01, 10:28
Reply from another thread, but to keep it all in one place:

Since I posted the same exact thing awhile back I figured I would chime in. Transitioning from Cisco devices has been painful. Their product was mature and well developed. We ran full https inspection with very little issues. Categorization was usually dead on and if it was not their response time and explanations were very good.

At this point the joke is what are we actually inspecting. We have many exceptions and bypasses in place. Many of them like choosing to bypass financial services for example had unintended consequences of causing other https bypasses to break. Support on this seems to be lacking in knowledge. Is it a third party system? I know their URL categorization is done by a 3rd party and it is comical how bad many of the categorizations are. (cyren.com)

Overall I hope they make improvements. They are needed.

RayPesek
2015-07-01, 21:10
We're running Websense appliances in explicit mode with full SSL decryption using v7.8.4 HF 11 and have just about zero issues. One thing I've noticed about many Websense customers is they never install upgrades or apply hotfixes and Websense regularly releases them. They've recently released hotfixes to upgrade OpenSSL and fix Logjam. We're a large bank so most of our traffic is HTTPS. We have almost nothing bypassed.

You definitely are correct, you are missing a lot. We see several blocks each week for malware coming down via HTTPS from infected legit sites as well as not-so-legitimate sites.

Personally I want my firewall to be an access control firewall and nothing else. URL filtering belongs on a proxy server and that's where we keep it.

PhoneBoy
2015-07-02, 00:56
Some of the issues come from SSL Inspection come from the different certificates the client side will see as a result of SSL Inspection.
This will be an issue regardless of what the SSL Inspection is done by (Check Point, Websense, whatever).

aweldon
2015-07-02, 08:46
Some of the issues come from SSL Inspection come from the different certificates the client side will see as a result of SSL Inspection.
This will be an issue regardless of what the SSL Inspection is done by (Check Point, Websense, whatever).

I think you are 100% correct that regardless of the solution there will have to be some exceptions put into place. With the Cisco product we were using these exceptions were very few and far between. In comparison, the Check Point HTTPS inspection needs exceptions on a weekly if not daily basis.

PhoneBoy
2015-07-02, 13:16
If you can share some of the exceptions you have to put in, aweldon, perhaps in a PM, I can check with our R&D.

PhoneBoy
2015-07-02, 14:27
After a little bit of research, I'm guessing some of the issues people are experiencing with having to enable bypasses and the like are the result of some HTTPS sites not supporting strong TLS ciphers.
A list of supported ciphers is provided here: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk104562
You can get a list of the ciphers a server supports by using this tool: https://www.ssllabs.com/ssltest/index.html

If you're having problems with a specific site when HTTPS Inspection is enabled, I recommend checking this tool to see if this is the issue.

RayPesek
2015-07-02, 21:53
That would match most of our bypass sites. For instance, the site where you download Oracle patches from supports RC4, two ciphers susceptible to Logjam and 112-bit 3DES and that's it. Once we applied the Logjam patch it no longer works. Unisys had their portal set to use solely SSLv3 so it stopped working when we chose to stop supporting SSLv3. Oracle 11G sites work with IE but no longer work with Firefox. There are a lot of sites that need to clean up their act. The RFC banning RC4 was issued in February 2015 and the RFC banning SSLv3 was issued a few weeks ago.

It's going to get a lot better or a lot worse in a year when PCI-DSS 3.1 kicks in fully and bans all versions of SSL, TLS 1.0 and some variants of TLS 1.1. That really leaves just TLS 1.2 as the viable alternative.

PhoneBoy
2015-07-03, 16:37
I'm guessing, however, Check Point is a bit more strict in what it allows compared to some of the other vendors, thus why more bypass rules are needed. :)

RayPesek
2015-07-03, 21:01
Did you just say it's better to be more strict so that bypasses have to be set so that less HTTPS sites are actually inspected? :-)

Ray

PhoneBoy
2015-07-03, 22:36
That's not what I said. :)
But your point is acknowledged.

dazzler
2016-02-11, 07:30
Browsing through my logs, I've seen various blocked traffic using UDP port 80 & 443. This lead me to do some reading on Google's QUIC protocol which sounds great. I was planning on allowing these UDP ports but wondered whether I'd lose the ability to perform HTTPS inspection on this traffic?

Looking at my logs, I've not inspected any traffic using these ports so i'm guessing it's a no!


Anybody know the official word from Checkpoint?

PhoneBoy
2016-02-11, 09:30
QUIC can not currently be HTTPS Inspected.

dazzler
2016-02-11, 11:46
QUIC can not currently be HTTPS Inspected.

Thanks for confirming, I'll block the application for now. It's a shame to block it though, if it brings improvements to speed :(

Do you know whether inspection will be possible at a later date?

PhoneBoy
2016-02-11, 23:38
Sorry, I have no idea if/when SSL inspection of QUIC will be possible.

aweldon
2016-09-12, 08:15
Bumping this up from the dead, PhoneBoy it has been a few months now just wondering if QUIC inspection is on Check Point's radar as of yet?

robs609
2016-09-24, 22:20
Nope.
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk111754

PhoneBoy
2016-09-25, 13:38
Here are a few facts that are likely contributing to this feature not being added to date:

1. The vast majority of sites still use regular HTTPS, not QUIC.
2. QUIC is not yet an IETF standard (though several drafts exist).
3. QUIC uses a crypto protocol that is interim and expected to be replaced by TLS/1.3.

Once things standardize and usage increases, I can see Check Point adding support for it (assuming it is feasible to do so).