HTTPS Inspection documentation for R80.30

[Garrett_DirSec]

update:   I incorrectly referenced one of the two primary "HTTPS INSPECTION" SK articles.   The fundamental argument that CP has not updated it's documentation/guides/SK/etc for R80.30 is still true.   my last quote below sums up the two primary articles.   thanks to @Dale_Lobb for identifying the SK problem. 

Hello - - I've been poking around looking for full details (and best practices) for the use of HTTPS inspection with R80.30+.

SK108202 "Best Practices - HTTPS Inspection" specifically states  "This sk is not relevant to R80.30". 

The next logical question "where is the updated SK document that does apply to R80.30?".     What is a customer supposed to think when encountering this information?

The "new" HTTPS inspection features of R80.30 are native to code (and not a hotfix like previous releases).   

I just had a conversation with customer that relayed various conversations he had with CP folks at last CPX.    In large majority of conversations, the various CP folks stated "just turn  ON HTTPS inspection" grossly oversimplifying a complicated topic . 

My point, HTTPS inspection is important,  we should be encouraging customers to use (at least, start testing),  R80.30 includes latest and great features, and I can't find unified document that consolidates and showcases all the features and discusses best practice commendations (for use and performance).

I suggest such a consolidated "one stop shop" for this information is critical.   I wasn't able to find on R80.30 docs, KB, or community using search strings "https decryption" or "https inspection".   I was trying to simulate what a customer would search for if they wanted to locate this information.

Please fix this issue.   thanks in adv.   -GA

[PhoneBoy]

FYI, We are currently planning to do a TechTalk on this very topic in a few weeks.
Register here: https://checkpoint.zoom.us/webinar/register/WN_GV0zSGUBSKGMOeUGL8xF0w

[Garrett_DirSec]

@PhoneBoy thanks for mention of upcoming session.  this is good.   

Since R80.30 has been "GA" for months and R80.40 already in "EA", I would expect to find some mature documentation to leverage the R80.30-specific HTTPS inspection features, best practices for tuning and performance, etc.    

side topic:  is there a content mgmt engine behind the current CP knowledgebase?  Is it a commercial solution of CP authored solution?   My assumption is that any SK where authors are nice enough to add "revision history" is simply an ad hoc entry.  

Wouldn't it be nice to have the revision history automated and auto-maintained at bottom of all articles? 

[PhoneBoy]

The biggest change in R80.30 is the addition of support for SNI as well as a few additional ciphers.
This actually resolves a lot of the long-standing issues we've had with HTTPS Inspection (specifically around bypass rules) as well as improves App Control and URL Filtering substantially.
The Best Practices really haven't changed much from sk108202.

Internally, the SK system has revision history.
We don't expose this publicly for various reasons, though specific SKs do have a manually maintained revision history.

[G_W_Albrecht]

I do find no line where SK108202 "Best Practices - HTTPS Inspection" specifically states  "This sk is not relevant to R80.30"

For me it looks to be valid  for all versions.

Last Modified

21-Feb-2019

[Garrett_DirSec]

hello -- the statement  "This sk is not relevant to R80.30" was a copy/paste directly from the SK.

It's laughable some oneone @ CP updated the doc, removed the statement, and didn't update the revision history.   

Another word of caution.   If you use the revision history alone, there should be various red flags since last supposed edit was  [19 June 2017], which was before R80.20 (and many of the "newer" HTTPS inspection features for which I want "best practice" details -- use, performance, etc).   A reminder that various performance enhancements and features were recently available as hotfix to R80.20 (and maybe R80.10).   They are now native to R80.30.   

I have seen various comments by folks, including @Dorit_Dor, to avoid R80.10 because it's "inferior" compared to newer releases (so I'm effectively ignoring that gateway release for this discussion).

[Ronen_Zel]

Hi Sir,

Regarding your comment:

 the statement  "This sk is not relevant to R80.30" was a copy/paste directly from the SK.

It's laughable some oneone @ CP updated the doc, removed the statement, and didn't update the revision history.   

I suspect you might be confusing this sk with a different one. The sk was last modified in February 2019 and it never included the statement This sk is not relevant to R80.30.

If you indeed confused this sk with a different one, please send me the correct SK ID and I will further look into this.

[Chris_Hoff]

I will state, when reviewing the article, I don't find the mention about the version. That being said, when reading through, all the references seem to be associated with R77.30 and below (e.g. enhancements are based on R77.30). Additionally, all the linked documentation is for versions R77.30 or lower.

Going back to the OPs question, is there an updated version of this article that describes the enhancements for versions R80.10 and greater? If not, will there be? Are we relegated to researching all the release notes for each version to determine this? 

[Dale_Lobb]

Hmmm.. That specific phrase, "This sk is not relevant to R80.30", can be found in sk104717: HTTPS Inspection Enhancements in R77.30 and above.

[Dale_Lobb]

SK104717 is th e only hit I get from Google, other than this community discussion.

It does kind of make you wonder: shouldn't SK104717 be updated so that it does apply to R80.30 and above?

[PhoneBoy]

Just to clarify the items mentioned as enhancements in sk104717 with respect to R80.30:

• SSL Handshake Acceleration - on by default in R80.30
• Perfect Forward Secrecy (PFS) - on by default since R80.30
• Support for AES-GCM - still supported in R80.30
• Probe Bypass - replaced by a different and better implementation in R80.30
• HTTPS Inspection Test Mode - not relevant for production traffic

In any case, seems like a R80.30 specific SK on this topic might be warranted.

[Garrett_DirSec]

hello and thanks @PhoneBoy 

agreed on the separate HTTPS inspection SK (config, features, and tuning) especially considering R80.40 has further "enhancements" (or enchantments... lol). 

[Garrett_DirSec]

Hey @Dale_Lobb  you are absolutely correct.  I will update original post with clarification of my mistake. 

The underlying issues:   

1. HTTPS inspection will be ongoing issue in 2020 and beyond.  ever increasing % of total traffic.    problematic PKI issue for roll-out.   BYOD problems. 
2. more and more of effectiveness of CP threat prevention features will rely in HTTPS inspection.
3. CP doesn't charge for HTTPS inspection (nor should they) but because of this they seem to leave feature/how-to/best-practice documentation updates in low priority. 

Compare the following and neither updated for R80.30.   one specifically states it's NOT for R80.30.   This means customers (and resellers) have to call support for insight.  that's not good... 

From my reseller eyes, I always ask myself "how would the competition position against this?"   CP is making it too easy (for the competition).

HTTPS Inspection Enhancements in R77.30 and above

Best Practices - HTTPS Inspection

[PhoneBoy]

@Ronen_Zel at least some of this should still apply to R80.30.

[Ronen_Zel]

A new sk for R80.x is currently being worked on by the SK Team and should be published soon.

Thank you all for bringing this to our attention.

[Pierre-Aymeric_]

Hi,

Are they writting a New sk ? 

Or updating HTTPS inspection best practice sk ?

[PhoneBoy]

New SK as indicated by Ronen.

[dannys · Accepted solution]

For your convenience we've published a new SK regarding What's new in HTTPS Inspection for R80.20 / R80.30 .

I hope that this SK will clear the fog around this topic.

Thank you all for raising this!

[Kevin_Stanton]

While I agree the technicalities of HTTPS inspection are problematic to say the least I would like to highlight the social aspects for our users. We had to get sign off from HR and the Union before we implemented the technology. We also agreed not to inspect Banking and Financial sites. More education for our poor users after years of telling them to check the little lock icon.