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

Note. What is written bellow only applies to Forefront TMG 2010 RC.
I was caught with this blog entry unfinished by the release of Forefront TMG 2010. It makes little point in finishing this blog entry, so I’ll just post it the way it is.
With the release of Forefront TMG 2010 final version some things might have changed in respect with the Outbound HTTPS Inspection. I wonder if something has changed with the default “all-over-the-place” pesky SSL 2.0 compatible Client Hello message… :)
I might come up with a new blog entry about these changes(if any) and what I did not post here.

One important (and new) feature in Forefront TMG 2010 RC is the Outbound HTTPS Inspection.
How that works is described here. However from there some info is missing. Unfortunately the explanation stops at step 3 “Presents the new certificate to the client computer, and establishes a separate SSL tunnel with it.”, which and what follows after is quite important from a security perspective.

If we take a capture on Forefront TMG 2010 RC’s external interface(bellow Forefront TMG 2010 RC is deployed as a firewall with two NICs, Forefront TMG 2010 RC is installed on Windows Server 2008 R2 SE), we can spot the SSL/TLS Client Hello message that Forefront TMG 2010 RC uses for the Outbound HTTPS Inspection.
This Client Hello message is a SSL 2.0 compatible Client Hello.
Basically it’s a SSL 2.0 Client Hello message, except that there are more cipher suites in the Cipher Specs, and the specified Protocol Version is the highest one supported by TMG, TLS 1.0. Under certain circumstances, I’ve noticed TLS 1.0 can be replaced with SSL 3.0 if the attempt with TLS 1.0 fails, a sort of a fallback mechanism(see bellow, not anymore in this blog entry).
This Client Hello message can be used with SSL 2.0, SSL 3.0 and TLS 1.0 servers.
This Client Hello message can pose problems with (some) servers that support ECDHE based cipher suites, and pick the wrong elliptic curve. See bellow.
It makes Forefront TMG 2010 RC to not append any TLS extensions as it would have been the case with a TLS 1.0 Client Hello message.
Forefront TMG 2010 RC might establish up to three different SSL 2.0 session with a web server(replying with SSL 2.0) when a client behind it does not support/allow SSL 2.0.
Based on the underlying Windows configuration, can be used containing no SSL 2.0 cipher suites whatsoever(if by some meaning or another you disabled such cipher suites), uh oh…
In theory, and most only in theory, but truly rarely in practice these days, this SSL 2.0 compatible Client Hello should allow Forefront TMG 2010 RC to establish more easily SSL/TLS sessions with most secure web servers. In fact, the default settings on all modern browsers(including Microsoft’s one) contradict this theory.
It kind of spoils the smartness(obviously and only in my opinion ;) ) of the SSL/TLS behavior of the Outbound HTTPS Inspection.
As can be seen I deeply question(obviously and only in my opinion ;) ) the use by default of this Client Hello message and the default support for SSL 2.0 for the Outbound HTTPS Inspection when the industry’s trend is to drop by default support for SSL 2.0 both on client and server side. Curiously to hear about this decision(year 2009) from Microsoft…
The deeply part is that since it was configured like so by default, while Forefront TMG 2010 RC makes use heavier than ever of SSL/TLS with the introduction of new features like the Outbound HTTPS Inspection or SSTP, still from its mmc there is no option to configure these settings, and some “global” underlying Windows settings can confuse admins of what which will affect. Also, this is a “security device”, not a web server.

So, theoretically, Forefront TMG 2010 RC can establish SSL 2.0 connections with web servers that may desired that. Remember that the web server is the one that chooses, based on the Client Hello message, the protocol version and the cipher suite to be used.
SSL 2.0 is rarely used in practice these days, and it is strongly recommended to be disabled. Simply put, SSL 2.0 has serious security flaws, quite unacceptable for the time being.
Many (most) secure web servers out there support TLS 1.0 and SSL 3.0. Some of them are still configured to support SSL 2.0 though(mostly being misconfigured or to support some legacy clients).
All modern browsers(IE8, Firefox 3.5, Chrome 3.x, etc.) disabled SSL 2.0 by default, some of them, like Opera, have dropped support for SSL 2.0, and did not implement it anymore. Libraries like GnuTLS also did not implement SSL 2.0 at all. All modern browsers have support for SSL 3.0 and TLS 1.0. Even older browsers like IE6 have enabled by default SSL 3.0(TLS 1.0 must be manually enabled).

Here is how it looks IE8’s default Client Hello message(IE8 on Windows 7):

This Client Hello message can be used with SSL 3.0 and TLS 1.0 servers.
It’s a TLS 1.0 Client Hello message, the specified Protocol Version is the highest one supported, TLS 1.0.
The server can respond with SSL 3.0 to this Client Hello message, and IE8 will accept this, as by default SSL 3.0 and TLS 1.0 are allowed:

So the question that arise from here, assuming you have behind Forefront TMG 2010 RC only clients that disabled SSL 2.0, is if Forefront TMG 2010 RC may weaken the protection afforded, willing to negotiate a weaker protocol, like SSL 2.0 with the real web server ?
At a glance, it looks like yes, but is it really so ?
Let’s take a look.

I’ve drawn this diagram:

According to this diagram the answer to the above question is no.

And to complete that picture, I’ve put some results within this table, the tests from where these results are bellowed:

This not only shows that Forefront TMG 2010 RC does not allow the downgrade of the SSL/TLS version used between it and the real server, but actually, based on the server’s settings can upgrade it(assuming you have some old clients behind it that do not support TLS 1.0).
Smart, but not that smart, it would have been really smart(obviously and only in my opinion ;) ) if it did not use a SSL 2.0 compatible Client Hello message by default, instead TLS 1.0 one and possibly to fallback to a SSL 3.0 one,, and disable by default support for SSL 2.0, I bet these would have covered 95% of possible situations out there…
And such a behavior would have stopped any misconfigured clients behind Forefront TMG 2010 RC to potentially use SSL 2.0.

We can test this using OpenSSL and its s_server option(note that I will rarely specify directly the SSL/TLS version to be used with it, mainly due to Forefront TMG 2010 RC’s SSL 2.0 compatible Client Hello message).
Here is how the test lab looks like:

• an external host mimicking a secure web server with the help of the OpenSSL’s s_server option, option which permits us to easy control the SSL/TLS version(s) available on this server.
• a client(Windows 7), web proxy client, behind Forefront TMG 2010 RC using IE8, on which we can easily enable and disable SSL 2.0, SSL 3.0 or TLS 1.0.
• we will start a Wireshark capture on the web server, and another one on the client.
• we will start the live logging on Forefront TMG 2010 RC.

Before we proceed, let’s take a quick look at the default cipher suites of interest in respect with the Outbound HTTPS Inspection on Forefront TMG 2010 RC.
Basically there are two “stages”:

• the cipher suites that can be negotiated between the client and Forefront TMG 2010 RC.
• the cipher suites that can be negotiated between Forefront TMG 2010 RC and the real destination web server. We saw these ones in the default Client Hello message presented above.

The differences between these two is that the certificate used for Outbound HTTPS Inspection on Forefront TMG 2010 RC restricts the usable cipher suites that can be negotiated between the client and Forefront TMG 2010 RC.
By default this uses a certificate containing a public RSA key, certificate signed with sha1RSA(self-signed certificate). Thus we cannot use any DSS or ECDSA cipher suites between the client and Forefront TMG 2010 RC.

Here is the list of cipher suites we can use between the client and Forefront TMG 2010 RC:

• TLS_RSA_WITH_RC4_128_MD5, 0x0004
• TLS_RSA_WITH_RC4_128_SHA,  0x0005
• TLS_RSA_WITH_3DES_EDE_CBC_SHA,  0x000a
• TLS_RSA_WITH_AES_128_CBC_SHA,  0x002f
• TLS_RSA_WITH_AES_256_CBC_SHA,  0x0035
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,  0xc013
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,  0xc014
• SSL_CK_RC4_128_WITH_MD5,  0x010080
• SSL_CK_DES_192_EDE3_CBC_WITH_MD5,  0x0700c0

To break this per protocol:

SSL 2.0

• SSL_CK_RC4_128_WITH_MD5, 0x010080
• SSL_CK_DES_192_EDE3_CBC_WITH_MD5, 0x0700c0
• Preferred SSL 2.0 cipher suite:
  SSL_CK_DES_192_EDE3_CBC_WITH_MD5, 0x0700c0

SSL 3.0

• SSL_RSA_WITH_RC4_128_MD5, 0 x0004
• SSL_RSA_WITH_RC4_128_SHA,  0x0005
• SSL_RSA_WITH_3DES_EDE_CBC_SHA,  0x000a
• Preferred SSL 3.0 cipher suite:
  SSL_RSA_WITH_RC4_128_SHA,  0x0005

TLS 1.0

• TLS_RSA_WITH_RC4_128_MD5, 0 x0004
• TLS_RSA_WITH_RC4_128_SHA,  0x0005
• TLS_RSA_WITH_3DES_EDE_CBC_SHA,  0x000a
• TLS_RSA_WITH_AES_128_CBC_SHA, 0 x002f
• TLS_RSA_WITH_AES_256_CBC_SHA,0 x0035
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,  0xc013
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,  0xc014
• Preferred TLS 1.0 cipher suite:
  TLS_RSA_WITH_AES_128_CBC_SHA, 0 x002f

Test 1

• IE8 on Windows 7 web proxy client, default SSL/TLS settings, only SSL 3.0 and TLS 1.0 enabled.
• the web server, accepts only SSL 2.0:
  openssl s_server -accept 443 -cert C:\CA\export\www.example.net.pem -no_ssl3 -no_tls1 –www
• This is logged on Forefront TMG 2010 RC. The error logged under the Malware Inspection Result field does not tell us much, what can matter is the error code, 0x80090331, which according to this should mean SEC_E_ALGORITHM_MISMATCH, “The client and server cannot communicate, because they do not possess a common algorithm.”. Which put in simple words may mean that the client and TMG did not find a common protocol version or cipher suite that they can use.

• on IE8 this error page will be shown, we can’t say what happened.

What happened:

• IE 8, web proxy client, issues a CONNECT www.example.net:443.
• Forefront TMG 2010 RC connects to the web server in order to obtain its certificate and verify it. As can be noted we use SSL 2.0.

• if the certificate is fine, Forefront TMG 2010 RC replies to the client with a HTTP/1.1 200 Connection established message.

• the client sends its Client Hello message which is incompatible with a SSL 2.0 server.

• As can be noted from above Forefront TMG 2010 RC FINs the connection with the client, as the server only wants to use SSL 2.0, which would imply to use between Forefront TMG 2010 RC and the real web server a weaker protocol than the client support. Also the connection with the real server is FINed.

• IE8’s fallback mechanism kicks in, but in vain, as it will fallback only to SSL 3.0(SSL 2.0 being disabled by default), which will also be FINed by Forefront TMG 2010 RC.

• as you may have noted no HTTP request was issued by Forefront TMG 2010 RC to the real web server, as a SSL/TLS session could not be established between the client and Forefront TMG 2010 RC.

Test 2

• IE8 on Windows 7 web proxy client, SSL 2.0, SSL 3.0 and TLS 1.0 allowed.

• the web server wants only SSL 2.0:
  openssl s_server -accept 443 -cert C:\CA\export\www.example.net.pem -no_ssl3 -no_tls1 –www
• This is logged on Forefront TMG 2010 RC. As can be noted this time the connection is successful, we have two logs, the last one is actually for the client’s HTTP GET request.

• on IE8 this page will be shown, this represents the details for the SSL 2.0 session between the Forefront TMG 2010 RC and the real destination web server.

What happened:

• IE 8, web proxy client, issues a CONNECT www.example.net:443.
• Forefront TMG 2010 RC connects to the web server in order to obtain its certificate and verify it. As can be noted we use SSL 2.0.

• if the certificate is fine, Forefront TMG 2010 RC replies to the client with a HTTP/1.1 200 Connection established message.
  The client sends its Client Hello message which is compatible with a SSL 2.0 server.
  And now Forefront TMG 2010 RC can reply with SSL 2.0, the same protocol used between it and the real server(as the server only wants to use SSL 2.0), resulting in a successful connection with the client.

Test 3

• IE8 on Windows 7 web proxy client, TLS 1.0 allowed.

• the web server wants only SSL 3.0:
  openssl s_server -accept 443 -cert C:\CA\export\www.example.net.pem -no_ssl2 -no_tls1 –www
• This is logged on Forefront TMG 2010 RC. Same error logged under the Malware Inspection Result, but there is a new Status, 1790 The network logon failed..
  The errors shown are not at their best…

• on IE8 same error page will be shown, we can’t say what happened.

What happened:

• IE 8, web proxy client, issues a CONNECT www.example.net:443.
• Forefront TMG 2010 RC connects to the web server in order to obtain its certificate and verify it. As can be noted we use SSL 3.0. However there is a problem here, the web server wants to use an AES cipher suite under SSL 3.0, which technically speaking is possible(but not as per RFC). However the SSL 3.0 implementation on Forefront TMG 2010 RC is a strict one and does not allow AES cipher suites under SSL 3.0, just under TLS 1.0+. Thus Forefront TMG 2010 RC FINs the connection with the server. At this point the client still waits for a response to its CONNECT request.

• some retries will occur, and the server will use an RC4 cipher suite. But instead of following this, let’s specify ourselves the cipher suite on the server.

Test 4

• IE8 on Windows 7 web proxy client, TLS 1.0 allowed.
• the web server wants only SSL 3.0, we use SSL_RSA_WITH_3DES_EDE_CBC_SHA,  0x000a, as the cipher suite:
  openssl s_server -accept 443 -cert C:\CA\export\www.example.net.pem -no_ssl2 -no_tls1 -cipher DES-CBC3-SHA -www
• This is logged on Forefront TMG 2010 RC. Same error logged under the Malware Inspection Result, same Status, 1790 The network logon failed..

• on IE8 same error page will be shown, we can’t say what happened.

What happened:

• IE 8, web proxy client, issues a CONNECT www.example.net:443.
• Forefront TMG 2010 RC connects to the web server in order to obtain its certificate and verify it. As can be noted we use SSL 3.0. This time a “good” cipher suite is selected by the server.

• if the certificate is fine, Forefront TMG 2010 RC replies to the client with a HTTP/1.1 200 Connection established message.
  The client sends its Client Hello message which is a TLS 1.0 one.
  And Forefront TMG 2010 RC replies with SSL 3.0, the same protocol used between it and the real server(as the server only wants to use SSL 3.0), which forces IE8 to FINs the connection as IE8 does not allow SSL 3.0.

• Note that (only) apparently Forefront TMG 2010 RC weakened the protocol using SSL 3.0, as the client’s Client Hello message, which is a TLS 1.0 one, was compatible with a SSL 3.0 server, so Forefront TMG 2010 RC could not say for sure if the client only supports TLS 1.0. It’s only apparently as the SSL/TLS session could not be established between the client and Forefront TMG 2010 RC.

Test 5

• IE8 on Windows 7 web proxy client, allow SSL 2.0 and SSL 3.0, basically we can simulate an older client with no support for TLS.
• the web server wants only TLS 1.0:
  openssl s_server -accept 443 -cert C:\CA\export\www.example.net.pem -no_ssl2 -no_ssl3 –www
• on IE8 this will be shown:

• which means we used TLS 1.0 between Forefront TMG 2010 RC and the real destination web server, Wireshark confirms this:

• We’ve used SSL 3.0 between Forefront TMG 2010 RC and the client, which means Forefront TMG 2010 RC actually upgraded the SSL/TLS version used with the real server(also upgraded the cipher suite used), Wireshark confirm this:

Test 6

Forefront TMG 2010 released.
Blog entry unfinished.

Further tests

We can play further till we confirm the all results from the above table, but I’m not going to picture them anymore, as it would make this blog post too long.

The security downgrade issue

As we saw, there isn’t a problem with a protocol version downgrade.
Still downgrade can occur in other ways.

One possibility:

• for the SSL/TLS cipher suite used. If you have clients configured to use only certain suites, it may appear the possibility that Forefront TMG 2010 RC to negotiate and use a weaker cipher suite win the real server.
  Say you have clients behind Forefront TMG 2010 RC configured in FIPS mode(maybe you want strong cipher suites and only TLS version(s) or FIPS compliance, assuming the MITM of Forefront TMG 2010 RC’s Outbound HTTPS Inspection is allowed), this will disallow any SSL protocols, disallow any RC4 based cipher suites, etc.
  If you do not configure Forefront TMG 2010 RC to use strong cipher suites or in FIPS mode also(the crypto API should be FIPS complaint), Forefront TMG 2010 RC’s Outbound HTTPS Inspection can use an weaker (RC4 based) cipher suites between it and the real server or break the FIPS cipher suites compliance.

To test this:

• say I put a client running Windows 7 in FIPS mode:

• IE8 on this Windows 7 machine, web proxy client, default SSL/TLS settings on IE8, now its Client Hello message looks like this:

• If I configure the OpenSSL s_server to use TLS 1.0 and an RC4 based cipher suite:
  openssl s_server -accept 443 -cert C:\CA\export\www.example.net.pem -no_ssl3 -no_ssl2 -cipher RC4-SHA –www

This will happen:

• the RC4 based cipher suite(TLS_RSA_WITH_RC4_128_SHA, 0x0005) will be used between Forefront TMG 2010 RC and the real server:

• and between the client the Forefront TMG 2010 RC’s preferred TLS 1.0 cipher suite which is TLS_RSA_WITH_AES_128_CBC_SHA, 0x002f.

• this time no smart trick, as with the SSL/TLS version(not so easy to achieve in case of the cipher suite, so to prevent this you have to act and configure Forefront TMG 2010 RC appropriately).

Another downgrade possibilities:

• also related to the cipher suite, Forefront TMG 2010 RC does not support DHE-RSA based cipher suites(more common in practice), only ECDHE-RSA based ones(less common in practice), so if you have a client(say Firefox 3.5) that supports such cipher suites behind Forefront TMG 2010 RC and a web server that has set as preferred cipher suite such a DHE-RSA based one, you will likely use a cipher suite that offers no ephemerality between Forefront TMG 2010 RC and the real web server, unless the server also prefers an ECDHE-RSA based one.
• if the web server uses a certificate containing a bigger public key, say a 2048-bits RSA one, the on-the-fly created certificate by TMG 2010 RC’s Outbound HTTPS Inspection and presented to the client, contains a 1024-bits RSA one, more specifically the public RSA key from TMG’s HTTPS Inspection default certificate(if you generate it using the TMG’s mmc).

There is another downgrade possibility, a more special one, that is the lack of ephemerality introduced by TMG 2010 RC’s Outbound HTTPS Inspection due to two factors(actually we’ve mentioned both above).
The on-the-fly created certificate by TMG 2010 RC’s Outbound HTTPS Inspection and presented to the client, contains a 1024-bits RSA one, more specifically the public RSA key from TMG’s HTTPS Inspection default certificate(if you generate it using the TMG’s mmc), it’s not that easy to generate on the fly RSA keys for every new certificate.
In practice, likely TLS 1.0 will be used between the client and Forefront TMG 2010 RC, as many browsers and web servers today support TLS 1.0. Forefront TMG 2010 RC’s preferred TLS 1.0 cipher suite is TLS_RSA_WITH_AES_128_CBC_SHA, 0x002f. This offers no ephemerality.
If one is able to capture the traffic between clients and TMG 2010 RC’s, traffic exposed to the Outbound HTTPS Inspection, and at some point in time the corresponding private key of the public RSA key from TMG’s HTTPS Inspection default certificate becomes compromised, then this someone will be able to decrypt all previously (captured) such traffic(when a cipher suite that offers no ephemerality was used).

If this is a issue or not depends:

• if the area between Forefront TMG 2010 RC and this client is considered to be a hostile zone.
• if something that should remain secret for a certain period was exchanged.
• at any moment, sensitive traffic sourced from a host or destined to a host can be excluded from the Outbound HTTPS Inspection.
• based on the SSL/TLS versions and cipher suites supported by clients behind it, for example, the administrator can override the preferred TLS 1.0 cipher suite on Forefront TMG 2010 RC setting an ECDHE one as preferred, say using the group policy SSL Configuration Settings, this may introduce some extra CPU usage due to the generation of the ECDHE keys. Using the group policy SSL Configuration Settings may be not so simple as it looks if you want to also disable SSL 2.0 and the SSL 2.0 compatible Client Hello from the Outbound HTTPS Inspection.

An example, using the group policy SSL Configuration Settings.
Bellow I’ve moved up the ECDHE_RSA based cipher suites, if a client supports one of them, it will be used between Forefront TMG 2010 RC and this client. Note that secp256r1(aka NIST P-256) and secp384r1(aka NIST P-384) elliptic curves can be used by the Forefront TMG 2010 RC. And I've removed any SSL 2.0 cipher suites.

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_RSA_WITH_RC4_128_SHA,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

There is a little problem, although I've removed any SSL 2.0 cipher suites, the SSL/TLS Client Hello message that Forefront TMG 2010 RC uses for the Outbound HTTPS Inspection is still a SSL 2.0 compatible one.  
It would be preferred to be a TLS 1.0 Client Hello message now in order to add TLS extensions to it, like the elliptic_curves TLS extension specifying the supported elliptic curves(note that although we’ve also moved up ECDHE-RSA based cipher suites in the SSL/TLS Client Hello message that Forefront TMG 2010 RC uses for the Outbound HTTPS Inspection the web server is still the one that chooses the cipher suite).

For example:

• I use OpenSSL and the s_server option, specifying ECDHE-RSA-AES128-SHA as the cipher suite, but do not specify the elliptic curve name to be used for ephemeral ECDH keys, the default one is sect163r2.
  We simulate a web server which will not receive the elliptic_curves TLS extension from the client, but the client says it supports ECDHE-RSA based cipher suites, so the server will choose its preferred elliptic curve, in our case sect163r2.
  openssl s_server -accept 443 -cert C:\CA\export\www.example.net.pem -no_ssl3 -no_ssl2 -cipher ECDHE-RSA-AES128-SHA –www

As expected we will have a jam, as only secp256r1(aka NIST P-256) and secp384r1(aka NIST P-384) elliptic curves can be used by the Forefront TMG 2010 RC, which will FIN the connection upon receiving the server’s Key Exchange.

• Forefront TMG 2010 RC attempts to fallback to SSL 3.0, keeping the silly Client Hello SSL 2.0 compatible message, which will get RSTed bellow.

• This is logged on Forefront TMG 2010 RC.

• And this is what Forefront TMG 2010 RC tells to the client in response to the client's CONNECT request:

In fact, speaking about the pesky SSL 2.0 compatible Client Hello, if I do not use the group policy SSL Configuration Settings option and instead disable from registry on Forefront TMG 2010 RC for client SSL 2.0 like bellow(I’ve deleted the DisabledByDefault entry), still Forefront TMG 2010 RC uses the Client Hello SSL 2.0 compatible message for Outbound HTTPS Inspection, that’s persistence… :)

Currently I find that I can disable this pesky Client Hello SSL 2.0 compatible message by enabling the System cryptography: Use FIPS 140 compliant cryptographic algorithms, including encryption, hashing and signing algorithms. group policy.
We can combine this with configuring the SSL Configuration Settings group policy to move up the ECDHE cipher suites.
The downside can be that this is a global setting and that we’ve disabled support for SSL 3.0 and RC4 based cipher suites. Especially the support for SSL 3.0 is a bad one, we may not want to do this in practice, at least not yet.

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,
TLS_RSA_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

To test these settings:

• I have on the web server server(the OpenSSL s_server option does not seem to recognize the elliptic_curves extension, so I’ve manually specified the elliptic curve to be used):
  openssl s_server -accept 443 -cert C:\CA\export\www.example.net.pem -tls1 -cipher ECDHE-RSA-AES128-SHA -www -named_curve prime256v1
• Here is the new Client Hello message of Forefront TMG 2010 RC, TLS 1.0 Client Hello message(and using only FIPS compliant cipher suites). As can be noted the session is successfully negotiated:

• how things look on the client(IE 8 on Windows 7, default SSL/TLS settings, web proxy client), we use an ECDHE-RSA cipher suite between client and Forefront TMG 2010 RC(what we wanted) and also an ECDHE-RSA cipher suite between the web server and Forefront TMG 2010 RC:

• note that we can use ECDHE-RSA cipher suites between client and Forefront TMG 2010 RC(what we wanted) and something else between the web server and Forefront TMG 2010 RC, I’ve just used for testing an ECDHE-RSA one between the web server and Forefront TMG 2010 RC.

…………

Unfinished due to the release of Forefront TMG 2010.