Mar 13
StoneGate 5.0: HTTPS / SSL inspection
Feature Previews, IPS, SMC - 
(3 votes, average: 5.00 out of 5)
Loading ...
Add comments
(3 votes, average: 5.00 out of 5) Loading ...
StoneGate IPS 5.0 allows you to protect your hosts and servers against attacks that are hidden inside HTTPS. Here are a couple of use cases what you may want to try with the StoneGate 5.0:
Client side protection:
- Detect and block attacks targeting the client Web browsers inside SSL tunnel.
- Protecting workstations and internal networks from malicious web servers.
Server side protection:
- Detect and block attacks targeting the HTTPS server inside SSL tunnel
- Protecting the server being compromised by the unauthorized uses
The HTTPS Inspection feature also provides support for usage of Certificate Revocation List (CRL). That list is updated via SMC.
You can also whitelist the Web sites you don’t want to inspect. There is a new HTTPS inspection policy element where you are supposed to add your users’ bank services etc.
7 Responses to “StoneGate 5.0: HTTPS / SSL inspection”
Leave a Reply
You must be logged in to post a comment.
March 13th, 2009 at 2:35 pm
Will this also work on inbound traffic – to protect a busy web farm with mant HTTPS servers ? – What is the impact on Firewall utilization?
I am looking forward to this capability and the other features of V5
DFoley
March 13th, 2009 at 2:59 pm
Oooh, cool!
How does it know it’s a malicious site or contains dangerous exploits/data/etc?
- IDS “Fingerprints” should work just fine as the SSL now gets terminated and re-built before the potential victim?
- Peer review sites such as http://www.mywot.come? ( Yet another cool Finnish “gadget” btw) More “open source”/community oriented.
- Sites that claim to be industry-leading reputation systems? I guess you could call them commercial blacklist sites. Not entirely sure how they actually work. You buy a subscription or something, or they’re a part of some proxy package from a vendor.
How configurable is the whitelist? I can whitelist http://www.foo.bar, but could I also whitelist *.foo.bar ? Could I even “whitelist” something like http://www.foo.bar/something/something/blah.html?
Can I be more lenient if a web site reputation is Super-Trustworthy-2000 ™ but uses a self signed certificate? That seal of trust was just a fantasy name for illustration purposes!
Really looking forward to the launch. Really hope you’ll get many opportunities to show how much better you are than the other big vendors. Really hope you’ll be able to show-case it where ever appropriate.
And by show-case, I’m talking show what this baby can do! Not just hand out some brochures and whitepapers that doesn’t really show how much more powerful Stonesoft management is in comparison with any of the other offerings currently available (read Checkpoint, Netscreen, etc ).
Keep these cool features coming!
March 16th, 2009 at 3:15 pm
Hi,
The HTTPS Inspection simply opens the SSL/TLS encryption and therefore allows the inspection of the HTTP content.
There is nothing new to the actual inspection part, beside of the decryption part. The same fingerprints / protocol analysis / browser version checks / etc that have been available before for the plain-text HTTP will now be available also for the HTTPS.
Thus this feature is not going to add any “commercial blacklisting” or other web site categorization functions.
And yes, the feature can be used to terminate the inbound HTTPS requests, inspect them and then forward to the web farm. I cannot say yet about the performance issues, though.
March 16th, 2009 at 6:02 pm
When it terminates a connection, can you define what ICMP code to send with the termination, for example, a code-3 type-9 for administratively prohibited network (such as for Tor nodes) or a code-40 type4/5 for needing authorization/authentication to access a resource (in case of direct linking or session hijacking, such as is done with many of the network attacks used against e-commerce systems)
March 16th, 2009 at 6:10 pm
In addition, I see you state you support CRL, and I am very glad to see that (similar products from another vendor I have worked with in the past only allow me to use predefined CRLs, which is not ideal, in cases such as the recent fake SSL certificates that have been circulating many underground sites since the public announcement in Decmeber of the MD5 hash exploit allowing creation of certificates that appear to be legitimately signed by a CA using MD5 when in fact they were not.)
Can we define a generic CRL to check against? or specific things to consider distrusted (for example, I set my web browser to block any site claiming to require export-strength limited keys, as those will commonly be created during man-in-the-middle attacks, 40 bit encryption is quite easily brute forced for creating false certificates that match a valid hash. I also don’t want to have to try to secure a U.S. government office when I have, for example, the Microsoft certificate defaults, including foreign [potentionally hostile] government controlled servers.)
Finally, can we define which CAs to check with, for example, an intranet CA used for all our management network’s encryption.
March 17th, 2009 at 12:57 pm
Johan Lindgren said: “How configurable is the whitelist? I can whitelist http://www.foo.bar, but could I also whitelist *.foo.bar ? Could I even “whitelist” something like http://www.foo.bar/something/something/blah.html?
Can I be more lenient if a web site reputation is Super-Trustworthy-2000 ™ but uses a self signed certificate? “
I’d like to make a small clarification about the HTTPS Inspection Policy. It’s not a whitelist in the sense of “sites that we consider secure” or “certificates from trusted certificate authorities”, but rather a list of domains that are excluded from decryption and inspection. My understanding is that the main reason for having the option for an HTTPS Inspection Policy has to do with possible legal restrictions: in some jurisdictions, decrypting and inspecting HTTPS traffic is prohibited by laws pertaining to the privacy of communications.
Additionally, you add the domain name of the site(s) you want to exclude from decryption and inspection to the HTTPS Inspection Policy, not the URL. The list of domains is checked against the domain name in the server’s certificate, so wildcards can only be used if they appear in the server’s certificate.
March 18th, 2009 at 10:04 am
Hi,
For TheGhostInTheMachine at comment #4:
When I used the word “terminate” I actually meant that the firewall acts as the end-point for the SSL tunnel. I did not mean the traffic blocking / denying in this context.
We also support the traffic blocking (refuse -action in the access rules) that politely sends a TCP RST message back to the connection originator. No ICMP error messages are sent for the blocked TCP connections.
- Joona