SSL/TLS sloppy implementation of Astaro Security Gateway v8's outbound HTTPS inspection feature

Today I was behind an Astaro Security Gateway v8 (8.102) doing outbound HTTPS inspection(the Scan HTTPS (SSL) Traffic option enabled).

Could not resist and took a look at its SSL Client Hello message.

Astaro uses a SSL 2.0 compatible TLS 1.0 Client Hello.

They do that probably for compatibility (whatever) reasons, maybe they need to allow SSL 2.0 connections to SSL 2.0 only servers by default.

A quick question came on my mind, does Astaro establish a SSL 2.0 session with a server when the client(browser) does not support SSL 2.0 and so does not advertise support for SSL 2.0 (all modern browsers come with SSL 2.0 support disabled by default) ?

Made a quick test, and the answer was yes.
This is opposed to what we saw within [2], where the implementation was careful enough to not allow the SSL/TLS version degrade between itself and the server compared with the one used between itself and the browser.

Also weak cipher suites(like ones using DES) can be used between Astaro and the destination server, although a browser may disable such cipher suites by default.

On the bright side, Astaro does not seem to have a fallback mechanism(quickly tested though, just with a RST segment and a Handshake Failure alert) in order to trick them with a SSL 2.0 version rollback attack, say like IE6 within [1].

The thing with HTTPS interception forward web proxies is that they became sort of SSL/TLS enforcers, they control the allowed SSL/TLS versions or cipher suites between them and the server, have their own list of trusted CAs, do certificate revocation status checking, etc.
This can be good or bad, depending on the default SSL/TLS settings of such an implementation.


[1] Random SSL/TLS 101 - SSL/TLS version rollbacks and browsers–SSLTLS-version-rollbacks-and-browsers.aspx

[2] A brief look at the SSL/TLS settings(behavior) of the Outbound HTTPS Inspection on Forefront TMG 2010 RC

Comments are closed