R80.30 HTTPS inspection?

[Yavor]

Hello,

We are in a process of implementing Check Point Application and URL filtering, and related to this we enabled HTTPS inspection.

We use R80.20 and we enabled probe bypass:

enhanced_ssl_inspection=1
bypass_on_enhanced_ssl_inspection=1

Some web sites are not properly working and we have to bypass from HTTPS inspection such using regex

.*sitename.com.*

Has anybody already tried how R80.30 HTTPS inspection works, and how that compares with the above described setup?

Yavor

[Rasim_Caner_GUR]

Hi,

According the sk104717 there is a notice;

This section is irrelevant for R80.30 and above, since a new probe mechanism was introduced (enabled by default) - customer should NOT use the 'old' mechanism (enhanced_ssl_inspection).

But i could not find any document or sk about to new prope mechanism for R80.30

Best Regard.

[John_Fenoughty]

It is very obvious what you mean by 'websites are not working properly' - this will be sites which fail on first connection with TLS or 'page not found' errors, sites which fail when you click on an authentication link and sites which fail when you are auto-redirected to SNI based content delivery network pages (CDN).

Anyone who has used HTTPS inspection on a real network with live users will have experienced some or all of these.

I can answer your actual question in three simple words:

Upgrade to R80.30!

Check out my comments on Office 365 and HTTPS inspection, 

https://community.checkpoint.com/t5/Access-Control-Products/O365-HTTPS-Inspection-Bypass/td-p/66863

these apply to tons of other sites too, the SNI fix alone resolves problems or potential problems with a HUGE percentage of the Internet.

Vitally, R80.30 kills enhanced_ssl_inspection=1 entirely - it doesn't matter how you set it, it gets ignored and this is because it totally isn't needed any more at R80.30.

I have done this upgrade on a number of live sites using HTTPS inspection and I then removed all HTTPS inspection overrides, I have had to put back one or two (Fedex and UPS for two) but only because of how utterly terribly these web apps are written. All other sites just popped into action after this upgrade, Check Point have done a fantastic job at R80.30 and they really need to shout out about it!

[Jens_Groth_Andr]

We recently upgraded to R80.30 and we noticed this regarding the probing mechanism:

The gateway will initiate the probe with it's interface IP as source, not the client IP or hide NAT address.

This can cause issues in case the gateway's IP is not allowed to access the service at the remote end, e.g. because only the hide NAT address has been whitelisted.

This may not be a change from R80.20 and earlier versions. But it did cause one or two issue for us, possibly because we now let less traffic bypass the HTTPS inspection.

[Nick_Doropoulos]

Hello Yavor,

Could you please elaborate on what you mean by websites are not working properly?

Thanks.

[Yavor]

Just to update that we migrated to R80.30 which solved all issues we had

It apparently works full scale for our company since the summer "Check Point Application and URL filtering + HTTPS inspection" and performs very well.

Best Regards

Yavor

[FERNANDO_DAMIEN]

Hi

You have chance....

3 customers upgraded to R80.30 JHF 50 and T76

All the 3 are suffering from latencies and web pages loading with display issues. The memory goes full and the only way to work around this issue is to disable HTTPS inspection either by setting the inspect rule to bypass or by disabling totally the HTTPS inspection option located on the GW/CXL object

This customers were coming from R77.30 and R80.10 on which https inspection was working fine with the probe bypass variable and the enhanced ssl variable set to 1

On R80.30, you have to remove those variables

Can you confirm that your fwkern.conf file is empty or at least, without any variables related to https inspection?

Dont you see lot of memory consumption on your GW's?

Thx

[HeikoAnkenbrand · Accepted solution]

If you only use URL filtering and application control, you do not need enabled https intercption.

R80.20+  with enabled HTTPS interception:

If the https interception is enabled, the parameter host from http header can be used for the url because the traffic is analyzed by active streaming. Check Point Active Streaming (CPAS) allow the changing of data, we play the role of “man in the middle”. CPAS breaks the connection into two parts using our own stack – this mean, we are responsible for all the stack work (dealing with options, retransmissions, timers etc.). An application is register to CPAS when a connection start and supply callbacks for event handler and read handler. Several protocols uses CPAS, for example: HTTPS, VoIP (SIP, Skinny/SCCP, H.323, etc.), Security Servers processes, etc. CPAS breaks the HTTPS connection into two parts using our own stack – this mean, we are responsible for all the stack work (dealing with options, retransmissions, timers etc.) 

R80.20+ without enabled HTTPS interception (SNI is used):

If the https interception is disabled, SNI is used to recognize the virtual URL for application control and url filtering.

More read here:

R80.x - SNI vs. enabled HTTPS Interception

Furthermore, https interseption (Check Point active streaming) in R80.30 has been significantly revised.

Active Streaming (CPAS)  -  Check Point Active Streaming active streaming allow the changing of data, we play the role of “man in the middle”. CPAS breaks the connection into two parts using our own stack – this mean, we are responsible for all the stack work (dealing with options, retransmissions, timers etc.). An application is register to CPAS when a connection start and supply callbacks for event handler and read handler.  In some scenarios, HTTP is also using CPAS, when IPS Web Intelligence protections are enabled. As for now, CPAS doesn't support accelerated traffic, this mean that each CPAS packet will be F2F.

R80.20 and above:

- CPAS works through the F2F path in R80.10 and R77.30. Now CPASXL is offered in SecureXL path in R80.20. This should lead to a higher performance.

R80.30 and above:
- Active streaming for https with full SNI support. This fixed many problems with older versions.

General overview:

• CPAS breaks the connection into two parts using our own stack – this mean, we are responsible for all the stack work (dealing with options, retransmissions, timers etc.)
• An application is register to CPAS when a connection start and supply callbacks for event handler and read handler.
• On each packet, CPAS send the application the packet data with cpas_read, allow the application to change the data as it like, and send the data forward with cpas_write.
• As for now, CPAS doesn't support accelerated traffic, this mean that each CPAS packet will be F2F.
• Since all the packet will pass SecureXL (even if they were F2F) it need to offload the connection to SecureXL.
• The offload is done on the outbound, without CPAS, the offload will occur when the SYN packet leave to the server, because CPAS break the connection, the first outbound will occur on the SYN-ACK that is sent to the Client
• CPAS does not synchronize connection between cluster members. If a failover occur and the connection was handled by CPAS then the connection will terminate. The only exception is VOIP connection.

CPAS is visible in the input fw monitor chain as "TCP streaming (cpas)" and in the output chain as "TCP streaming (cpas)" and "TCP streaming post VM (cpas)".

Active Streaming – https:

With PSL, connection that is encrypted with SSL (TLS) was not supported, the reason for this is that the encryption keys are known only to the Client and Server since they are the one that initiated the connection (preformed the SSL handshake), because of this we couldn’t get the data out of the packet and the application couldn’t scan it for malicious information. CPAS plays the rule of “man in the middle”, because of this, it can intercept the SSL handshake and change the keys so he will be able to understand the encryption. The Client preform an SSL handshake with the gateway (thinking it is the Server) while the Server preform SSL handshake with the gateway (thinking he is the Client). The gateway have both keys and he’s able to open the encryption, check the packet and re-encrypt the packet with the corresponding keys. In order to encrypt / decrypt the SSL connection, CPAS add another layer before the application queue. The new layer will send the packet to the SSL engine for decryption/encryption and then resume the normal flow.

Active Streaming – https content step by step:

Packets of SSL handshake are passed to the SSL engine to exchange keys. When the connection and the SSL handshake is fully established, an hook will be register for this connection to handle the decrypt / encrypt of the packets. When a packet arrive to CPAS, a trap will be sent and the SSL engine will receive the encrypted packet, decode the packet and return it to CPAS. The packet will enter the receive queue and the application will be able to work on it, once he done he will send it to the write queue. The packet will pass to the SSL engine for encryption and pass to the other side (Client, Server).

More read here:

R80.x - Security Gateway Architecture (Content Inspection)