- CheckMates
- :
- Products
- :
- General Topics
- :
- Re: Preventing TLS 1.0 to a specific destination I...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Preventing TLS 1.0 to a specific destination IP
Hi all,
We have a scenario where one of our external facing web servers is showing to support TLS 1.0 and 1.1 despite disabling this locally on the server. The reason seems to be because HTTPS inspection is used on the Checkpoint firewall with this server, and the firewall is enabling it.
I did see THIS previous checkmates post which shows how to set the minimum supported SSL version globally with the GuiDBedit tool, however this would obviously prevent ALL TLS 1.0 connections. We only want to prevent it to this specific server.
Also sk126613 shows how to disable specific ciphers, but this is for the whole gateway, again impacting ALL TLS connections.
One method we thought for sure would work was creating an IPS exception for TLS 1.0 & 1.1 with the action set to Prevent with the server destination IP. But this unfortunately did not work, the exception isn't triggered, the signature seemingly isn't identified.
We also noticed there are default objects in smartconsole named tls1.0 and tls1.1, we tried creating a standard firewall rule (also in the Application policy) to block this tls traffic destined to the server IP. But we found it blocked ALL https traffic (the objects seemingly match against tcp/443)
I was wondering if any of you guys had any other ideas of things we could try?
Thanks
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi all, apologies I forgot to update this sooner with the resolution. So we had the global IPS expectation in place to prevent TLS 1.0 & 1.1 traffic destined for our target web servers, however the traffic was still being permitted.
It turns out that the default profile behavior for the TLS 1.0 and 1.1 protections is "inactive". We changed this to "Detect" for the specific profile, and then the prevent exception became active and began blocking the TLS traffic. Which makes sense, having the protection set to "Inactive" essentially turns the protection off I guess, so any exception you make using the protection won't be enforced.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm guessing this service won't work the way you expect until you enable the Protocol Signature for it:
Push policy after making this change.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you, I did try this but unfortunately the TLS1.0 protocol still shows to be supported when testing.
I noticed that I could however still access the server on HTTPS, so it seemingly isn't blocking all HTTPS traffic as the rule did previously before enabling this setting. But the rule isn't showing to be blocking anything either in it's traffic logs.
I did try placing the rule as both a Network and Application rule to ensure both policies enforced this (Application blade is enabled).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So If I understood the question correctly you are intercepting the inbound https traffic using certificate and have put source as any in your https inspection rule? Then why not go for WAF or something - That way you will get granular inspection.
I always have taken this approach and for my inbound servers have deployed the waf. Nowa days I am using Appsec with Nginx instead of intercepting inbound traffic.
Blason R
CCSA,CCSE,CCCS
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks, we have been looking into WAF products, it does seem like this type of solution would be more suitable to be honest.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi all, apologies I forgot to update this sooner with the resolution. So we had the global IPS expectation in place to prevent TLS 1.0 & 1.1 traffic destined for our target web servers, however the traffic was still being permitted.
It turns out that the default profile behavior for the TLS 1.0 and 1.1 protections is "inactive". We changed this to "Detect" for the specific profile, and then the prevent exception became active and began blocking the TLS traffic. Which makes sense, having the protection set to "Inactive" essentially turns the protection off I guess, so any exception you make using the protection won't be enforced.
