As the title says this one is merely a quick blog entry messing a little bit with the preferred TLS cipher suite on TMG Forefront Beta 3(I’m using it bellow installed on Windows Server 2008 SP2 Standard).
We will discuss in a future blog entry about how we can discover the SSL/TLS cipher suites enabled on ISA Server or Forefront TMG Beta 3, learn what we need to look for, the easy way using various online scanners(analyze which of them is better, up-to-date, etc.), or using various tools designed just for that, or getting deeper with OpenSSL or GnuTLS.
With Windows Vista, Windows Server 2008 and above, Microsoft has hardened the TLS cipher suites, see:
http://technet.microsoft.com/en-us/library/cc766285(WS.10).aspx
http://msdn.microsoft.com/en-us/library/aa374757(VS.85).aspx
http://technet.microsoft.com/en-us/library/cc771361(WS.10).aspx
As said I’ve installed TMG Forefront Beta 3 on Windows Server 2008 SP2.
What bothers me a little is that Microsoft still seems to not have support for DHE-RSA TLS cipher suites, thus an absence of PFS. For example, in case of TLS_RSA_WITH_AES_128_CBC_SHA or TLS_RSA_WITH_AES_256_CBC_SHA, if the server’s private key is compromised(stolen) somehow(if you’ve protected with SSL some sensitive traffic, you need to be careful what you do with an expired certificate and its associated private key), past traffic that might have been captured/recorded can be decrypted(assuming the needed SSL sequences have been recorded) by the one now in possession of the server’s private key. We did something similar with Wireshark here.
TLS_DHE_RSA_WITH_AES_256_CBC_SHA or TLS_DHE_RSA_WITH_AES_128_CBC_SHA seeming to miss from the picture, we have access to ECDHE, more specifically to TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA and TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA. Actually we have access to TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA and TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA too, but we need an ECDSA-signed server certificate for that. See:
http://www.ietf.org/rfc/rfc4492.txt
http://technet.microsoft.com/en-us/library/cc766285(WS.10).aspx
The preferred cipher suite on Windows Server 2008 SP2 is TLS_RSA_WITH_AES_128_CBC_SHA.
So the TMG Forefront Beta 3 on Windows Server 2008 SP2 from my lab prefers this one. This TMG also servers SSTP connections in addition of publishing secure web servers.
Since I want some PFS in my lab, I’ve decided to move TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as the preferred cipher suite.
Note that the computational cost incurred by Forefront TMG Beta 3 is higher for ECDHE_RSA than for the traditional RSA key exchange, which does not provide forward secrecy.
On Windows Server 2008 is somehow easier to configure the TLS cipher suites, as this can be done from the mmc. I say somehow as the way the cipher suites are listed makes editing them not quiet handy.
On my lab I’ve modified this on the TMG Beta 3 machine from start\run:gpedit.msc and Computer Configuration\Administrative Templates\Network\SSL Configuration Settings. If your TMG Beta 3 machine is under some domain group policy you may need to make this change there.
Double-click the SSL Cipher Suite Order and select Enabled:
You should copy the cipher suites within a text editor in order to edit them easier.
I’ve moved for the start, just to see how things go, the TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256 cipher suite at the beginning of the list(there are similar ones for P384 and P521, NIST curves P-256(secp256r1), P-384(secp384r1), and P-521(secp521r1)):
And while I was there, I’ve also deleted the SSL_CK_RC4_128_WITH_MD5 and SSL_CK_DES_192_EDE3_CBC_WITH_MD5 SSL2.0 cipher suites.
Save the settings and reboot the TMG Beta 3 machine.
Note that this is a global setting, when a SSTP client connects now if it lists the TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA in its Hello message cipher suites list, TMG Beta 3 will try to use this cipher suite(if the client supports the corresponding curve, the client may append to its Hello message the Supported Elliptic Curves Extension containing 0x0017 corresponding to secp256r1(23)), or in reverse when TMG Beta 3, while doing HTTPS inspection connects to a remote secure web server, it will list first the TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA within its Hello message cipher suites(that may matter little as the server is the one which picks the preferred cipher suite from the client’s list).
For example, a client Hello message from my TMG Beta 3 machine(while doing HTTPS inspection) to a remote secure web server before the change(actually there is something interesting here, there are 14 cipher suites, if I had used IE 8 on Windows Server 2008 SP2 would have been only 12 cipher suites, more specifically the last two SSL 2.0 ones won’t be there(SSL 2.0 disabled by default in IE8) , they are enabled on Windows Windows Server 2008 SP2 for the server side(for example if I connect to a secure web site on IIS 7.0 I can use SSL2_RC4_128_WITH_MD5, not sure why TMG Beta 3 appends them to the cipher suites list of its client SSL hello message -it is recommeded to disable SSL 2.0 by default-):
And a client Hello message from my TMG Beta 3 machine(while doing HTTPS inspection) to a remote secure web server after the change:
We can make a quick test with OpenSSL from a remote machine, say connecting to the SSTP remote VPN server on TMG Beta 3(assuming its enabled), like bellow, to see what cipher suite will select TMG Beta 3 now from the proposed list:
Which means that the client will propose something like:
And TMG Beta 3 will select its preferred cipher suite from that list:
