[Update 19.10.2009]
See this.
-----------
As you may know(we’ve mentioned here) at tls.woodgrovebank.com, Microsoft put the Microsoft Interop Test Server, which supports the following TLS/SSL protocols and cipher suites:
http://tls.woodgrovebank.com/Ciphersuites.htm
The server probably runs Windows Server 2008 R2, which introduced support for TLS 1.2:
http://technet.microsoft.com/en-us/library/dd560644(WS.10).aspx
The interop server from tls.woodgrovebank.com supports the following RFCs:
http://tls.woodgrovebank.com/RFC.htm
The features shown by Microsoft on the server side regarding SSL/TLS are impressive for the current time, and as noted by Ivan Ristic, Microsoft momentarily leads the way with Windows Server 2008 R2 in this area.
Unfortunately, on the client side(browser), the (default) configuration of IE8 on Windows 7 does not match the capabilities shown on tls.woodgrovebank.com in respect with SSL/TLS.
In fact, (possibly surprising for some), from the browsers mentioned bellow, it was not IE8 on Windows 7 that was capable of accessing “all” the web sites on tls.woodgrovebank.com(more exactly the web sites running on TCP ports 443, 25000, 25001, 25002, 25003, 25004) with the default settings(regardless of the TLS protocol used, either using TLS 1.0, TLS 1.1 or TLS 1.2, unless I make some tweaks so that IE8 will be able to do that using TLS 1.0 or TLS 1.1), it was Firefox 3.5.3(on Windows 7, using TLS 1.0, without any tweaks) that did that.
You can find another TLS 1.2 servers at(if you want to test your browser):
https://www.mikestoolbox.net/
and at(see this, the SECG's ECC/TLS test server hosted by Certicom, it has support for AES GCM cipher suites too):
http://tls.secg.org/
Also there are some servers, which (as writing) do not support TLS 1.2, at(they can be useful in testing the ECC capabilities of your browser):
http://ecc.fedora.redhat.com/
http://dev.experimentalstuff.com:8082/chooser.html
So what web sites are on tls.woodgrovebank.com ?
To list a few:
- a secure web site, listening on TCP port 25000, using a server certificate with the following attributes:
Signature algorithm: sha1RSA
Signature hash algorithm: sha1
Public Key: 2048-bits RSA
https://tls.woodgrovebank.com:25000/
- a secure web site, listening on TCP port 25001, using a server certificate with the following attributes:
Signature algorithm: sha1DSA
Signature hash algorithm: sha1
Public Key: 1024-bits DSA
https://tls.woodgrovebank.com:25001/
- a secure web site, listening on TCP port 25002, using a server certificate with the following attributes:
Signature algorithm: sha512ECDSA
Signature hash algorithm: sha512
Public Key: 256-bits ECC ECDH_P256
https://tls.woodgrovebank.com:25002/
- a secure web site, listening on TCP port 25003, using a server certificate with the following attributes:
Signature algorithm: sha512ECDSA
Signature hash algorithm: sha512
Public Key: 384-bits ECC ECDH_P384
https://tls.woodgrovebank.com:25003/
- a secure web site, listening on TCP port 25004, using a server certificate with the following attributes:
Signature algorithm: sha512ECDSA
Signature hash algorithm: sha512
Public Key: 256-bits ECC ECDH_P512
https://tls.woodgrovebank.com:25004/
Also there is a secure web site listening on the “regular” TCP port 443 using a “regular” RSA server certificate(actually it is the same server certificate as the one on the web site using TCP port 25000), and on TCP ports 25005-25009 there are sort of “replicas” of the web sites using the 25000-25004 TCP ports, the 25005-25009 ones should require a client certificate(I won’t comment on these ones, as I haven’t (yet) played around with them).
So, we need browser(s) to access the web sites from tls.woodgrovebank.com(more exactly the web sites running on TCP ports 443, 25000, 25001, 25002, 25003, 25004), browsers capable of using say, TLS 1.2 and ECC.
It appears like a logical choice to start first with IE8 running on Windows 7(RTM, x64), the “client side partner” of Windows Server 2008 R2.
Configure IE8 on Windows 7(RTM, x64) to use TLS 1.0, TLS 1.1, TLS 1.2:
Now IE8’s Client Hello message should look something like:
As opposed to what was when the default settings where in place(use only SSL 3.0 and TLS 1.0):
And let’s proceed.
At a glance, we can access with IE8 the tls.woodgrovebank.com web sites running on TCP ports:
- 443, the one with the "regular" RSA certificate, RSA 2048-bits public key(signed with sha1RSA)
- 25000, the one with the "regular" RSA certificate, RSA 2048-bits public key(signed with sha1RSA)
- 25001, the one with the DSA certificate, 1024-bits DSA public key(signed with sha1DSA)
- 25002, the one with the ECDH P_256 public key certificate(signed with sha512ECDSA)
- 25003, the one with the ECDH P_384 public key certificate(signed with sha512ECDSA)
But not the one running on port 25004, the one with the ECDH P_521 public key certificate(signed with sha512ECDSA).
At a closer look with Wireshark, in fact we’ve only accessed using IE8 with TLS 1.2 the tls.woodgrovebank.com web sites running on TCP ports:
- 443
- 25000
- 25001
And accessed with IE8 using TLS 1.0 the tls.woodgrovebank.com web sites running on TCP ports:
- 25002
- 25003
Let’s have a look on what happens with IE8 and the tls.woodgrovebank.com web site running on TCP port 25004.
As we can see the server rejects our Client Hello messages, and an interesting thing can be observed, IE8’s fallback mechanism, it tries first with TLS 1.2, then after the server has RSTed the connection, it tries with TLS 1.0:
Actually, to further exemplify this fallback mechanism, say I configure IE8 on Windows 7 like(enable SSL 3.0 too):
And attempt now to access the tls.woodgrovebank.com web site on port 25004, we can notice we fallback from TLS 1.2 to TLS 1.0 and further to SSL 3.0(as can be noted TLS 1.1 is omitted from the fallback mechanism), the fallback mechanism is nice from a functional point of view, but not from a security point of view(as may “overwrite” TLS’ own downgrade mechanisms):
So what seems to be the obstruction(s), why we could not access using TLS 1.2 the tls.woodgrovebank.com web sites running on ports 25002/25003/25004 and could not access at all the tls.woodgrovebank.com web site running on port 25004(either using TLS 1.0, TLS 1.1 or TLS 1.2) ?
Let’s take a closer look at IE8 on Windows 7 TLS 1.2 Client Hello message:
The cipher suites sent by IE8 seem to be fine, plenty of them, so the server should not complain here.
An area of interest would be the Transport Layer Security (TLS) Extensions. These extensions are described within:
- http://www.ietf.org/rfc/rfc3546.txt, RFC3546 Transport Layer Security (TLS) Extensions
- http://www.ietf.org/rfc/rfc4366.txt, RFC4366 Transport Layer Security (TLS) Extensions, obsoletes RFC3546
- http://www.ietf.org/rfc/rfc4681.txt, RFC4681 TLS User Mapping Extension
- http://www.ietf.org/rfc/rfc4492.txt, RFC4492 ECC Cipher Suites for TLS
- http://www.ietf.org/rfc/rfc5246.txt, RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2
What TLS extensions IE8 sends within the TLS 1.2 Client Hello message(pictured above), remember that IE8 on Windows 7 and the server(Windows Server 2008 R2) should (in theory) make use of the same crypto API and same TLS 1.2 implementation(so the server should not “jam” when it receives a certain extension as should support them all):
- server_name, Server Name Extension, a mechanism for a client to tell a server the name of the server it is contacting. Can be used with TLS 1.0, TLS 1,1 and TLS 1.2. Things look fine here.
- status_request, Certificate Status Request Extension, some (constrained) clients may wish to use a certificate-status protocol such as OCSP to check the validity of server certificates, in order to avoid transmission of CRLs. Servers that receive a client hello containing this extension may return a suitable certificate status response to the client along with their certificate. Can be used with TLS 1.0, TLS 1,1 and TLS 1.2. This should not bother us either.
- elliptic_curves, Supported Elliptic Curves Extension, indicates the set of elliptic curves supported by the client. IE8 indicated to the server that it supports secp256r1(aka NIST P-256; value 23 = “0x0017”) and secp384r1(aka NIST P-384; value 24 = “0x0018”) elliptic curves, see this for more details about what’s supported on Windows. Can be used with TLS 1.0, TLS 1.1 and TLS 1.2. Here troubles start, IE8 did not send secp521r1 (aka NIST P-521; value 25 = “0x0019”), because apparently P_521 cipher suites are not enabled by default on Windows 7. The troubles should be with the tls.woodgrovebank.com web site running on port 25004, as this web site uses an ECDH P_521 public key certificate. If IE8 does not send this elliptic curve, it won’t be able to connect to the tls.woodgrovebank.com web site running on port 25004(the one with the ECDH P_521 public key certificate), either using TLS 1.0, TLS 1.1 or TLS 1.2 if it appends the elliptic_curves extension to its Client Hello message(which IE8 on Windows 7 does).
- ec_point_formats, Supported Point Formats Extension, this extension is usually the “cousin” of the elliptic_curves extension. It indicates the set of point formats that the client can parse. What IE8 sent for this extension might be considered “common”, it told to the server that it can parse only the uncompressed point format. Can be used with TLS 1.0, TLS 1.1 and TLS 1.2. This should not bother us either.
- signature_algorithms, Signature Algorithms Extension, indicates to the server which signature/hash algorithm pairs may be used in digital signatures(the client is willing to use them for verifying messages sent by the server, say server certificates, server key exchange). Can be used with TLS 1.2. IE8 has sent the following algorithms: sha256RSA(value "0x0401" ), sha384RSA(value "0x0501"), sha1RSA(value "0x0201"), sha256ECDSA(value "0x0403"), sha384ECDSA(value "0x0503"), sha1ECDSA(value "0x0203") and sha1DSA(value "0x0202"). And troubles again, as IE8 does not send sha512ECDSA(value "0x0603"), remember that the server’s certificate is signed with sha512ECDSA on the tls.woodgrovebank.com web sites running on ports 25002/25003/25004.
So, before we continue with IE8, let’s make the tls.woodgrovebank.com web sites running on TCP ports 25002/25003/25004 say hello using TLS 1.2.
I’m going to use a basic Python script for that, mimicking a TLS 1.2 Client Hello message with these TLS extensions:
- signature_algorithms, I will make sure sha512ECDSA is present.
- elliptic_curves, secp521r1 (aka NIST P-521) elliptic curve will be also present.
- ec_point_formats, uncompressed point format
You may like to take a look at:
http://www.iana.org/assignments/tls-parameters/
http://www.iana.org/assignments/tls-extensiontype-values/
Here is the script(note that I’ve described the meaning of the hex bytes sent, the descriptions do not necessarily follow RFCs' guidance or naming conventions):
#!/usr/bin/python
from socket import socket
from time import sleep
raddr = "tls.woodgrovebank.com", 25002
test = (
# ----> Start TLS Record Protocol
"\x16" # ContentType: Handshake
"\x03\x03" # ProtocolVersion: TLS 1.2
"\x00\x91" # Length
# ---> Start Handshake Protocol
"\x01" # HandshakeType: ClientHello
"\x00\x00\x8d" # Length
"\x03\x03" # ProtocolVersion: TLS 1.2
"\x4a\xb2\x5e\x62" # Random: gmt_unix_time
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" # Random: random_bytes (28 bytes)
"\x00" # SessionID
"\x00\x34" # CipherSuites Length
# -> Start CipherSuites
"\x00\x3c" # TLS_RSA_WITH_AES_128_CBC_SHA256
"\x00\x2f" # TLS_RSA_WITH_AES_128_CBC_SHA
"\x00\x3d" # TLS_RSA_WITH_AES_256_CBC_SHA256
"\x00\x35" # TLS_RSA_WITH_AES_256_CBC_SHA
"\x00\x0a" # TLS_RSA_WITH_3DES_EDE_CBC_SHA
"\x00\x05" # TLS_RSA_WITH_RC4_128_SHA
"\x00\x04" # TLS_RSA_WITH_RC4_128_MD5
"\x00\x16" # TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
"\x00\x33" # TLS_DHE_RSA_WITH_AES_128_CBC_SHA1
"\x00\x39" # TLS_DHE_RSA_WITH_AES_256_CBC_SHA1
"\x00\x67" # TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
"\x00\x6b" # TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
"\xc0\x27" # TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
"\xc0\x13" # TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
"\xc0\x14" # TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
"\xc0\x2b" # TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
"\xc0\x23" # TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
"\xc0\x2c" # TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
"\xc0\x24" # TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
"\xc0\x09" # TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
"\xc0\x0a" # TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
"\x00\x40" # TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
"\x00\x32" # TLS_DHE_DSS_WITH_AES_128_CBC_SHA
"\x00\x6a" # TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
"\x00\x38" # TLS_DHE_DSS_WITH_AES_256_CBC_SHA
"\x00\x13" # TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
# <- End CipherSuites
"\x01" # CompressionMethods Length
"\x00" # CompressionMethods: Null
"\x00\x30" # Extensions Length
# --> Start Extension: signature_algorithms
"\x00\x0d" # Extension: signature_algorithms
"\x00\x1a" # Extension signature_algorithms Length
"\x00\x18" # signature algorithms Length
# -> Start signature algorithms
"\x02\x01" # sha1;rsa
"\x03\x01" # sha224;rsa
"\x04\x01" # sha256;rsa
"\x05\x01" # sha384;rsa
"\x08\x01" # sha512;rsa
"\x02\x03" # sha1;ecdsa
"\x03\x03" # sha224;ecdsa
"\x04\x03" # sha256;ecdsa
"\x05\x03" # sha384;ecdsa
"\x06\x03" # sha512;ecdsa
"\x02\x02" # sha1;dsa
"\x01\x01" # md5;rsa
# <- End signature algorithms
# <-- End Extension: signature_algorithms
# --> Start Extension: elliptic_curves
"\x00\x0a" # Extension: elliptic_curves
"\x00\x08" # Extension elliptic_curves Length
"\x00\x06" # elliptic curves Length
# -> Start elliptic curves
"\x00\x17" # secp256r1
"\x00\x18" # secp384r1
"\x00\x19" # secp521r1
# <- End elliptic curves
# <-- End Extension: elliptic_curves
# --> Start Extension: ec_point_formats
"\x00\x0b" # Extension: ec_point_formats
"\x00\x02" # Extension ec_point_formats Length
"\x01" # ec_point_formats Length
# -> Start point formats
"\x00" # ec_point_formats: uncompressed point format
# <- End point formats
# <-- End Extension: ec_point_formats
# <--- End Handshake Protocol
# <---- End TLS Record Layer
)
s = socket()
s.connect(raddr)
s.send(test)
reply = s.recv(1024)
s.shutdown(1)
print 'Received Reply:\n', repr(reply)
If I run this script against tls.woodgrovebank.com web site running on port 443(just change the port as desired), the TLS 1.2 Client Hello message sent will look like:
So let’s knock with TLS 1.2 on the door of the tls.woodgrovebank.com web sites running on TCP ports 25002/25003/25004, and see if someone is home.
Looks like someone is indeed home, and IE8 on Windows 7 does not know how to knock:
So can we teach IE8 on Windows 7 how to knock with TLS 1.2 ?
Possibly, but (currently) I don’t know how to do that in respect with tls.woodgrovebank.com, more specifically, how to make IE8 send the needed signature algorithm(sha512ECDSA) within the TLS 1.2 signature_algorithms extension.
I’ve played with various registry entries(I think I’ve invented some of them), with no success(as writing these things are not documented).
I’ve sent an email to Microsoft’s IE’s team blog, no answer received till today.
Let’s tweak the settings a little bit on the client(Windows 7), so that we will have IE8 able to connect to “all” the web sites on tls.woodgrovebank.com(more exactly the web sites listening on TCP ports 443, 25000, 25001, 25002, 25003, 25004) using either TLS 1.0 or TLS 1.1.
I will configure the SSL Configuration Settings group policy to make sure P_521 cipher suites are enabled on the server(might work with registry values, assuming one knows these values).
I’ve enabled on the client:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521,
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_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521,
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_P256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
As can be seen I’ve used only some cipher suites as the text box on that group policy where we enter the cipher suites takes only 1023 characters or so, and I wanted to have enabled on the client RSA, ECDSA and DSS cipher suites, thus I had to make a quick “selection” from what I would have wanted to enable on the client.
Now IE8 should be able to connect, either using TLS 1.0 or TLS 1.1 to the tls.woodgrovebank.com web site running on TCP port 25004 too, the IE8 TLS 1.0 and TLS 1.1 Client Hello messages(after configuring the SSL Configuration Settings group policy):
These modifications do not have any impact on the signature_algorithms extensions from IE8’s TLS 1.2 Client Hello message, so IE8 still won’t be able to connect to any of the tls.woodgrovebank.com web sites running on TCP port 25002/25003/25004 using TLS 1.2, as it misses the needed signature algorithm:
However, as might be noted from the above screen shot, with the SSL Configuration Settings group policy on the client configured like above, something has “happened” to IE8 on Windows 7, I’ve lost the fallback mechanism, it just tries with TLS 1.2, and then it stops(I did not dig to see if it has to do with how I’ve configured the SSL Configuration Settings group policy or if the simple fact of enabling that policy will “erase” the fallback mechanism).
Actually, to have IE8 on Windows 7 speak TLS 1.2 with a server using an ECDSA signed certificate containing an ECC public key, I’ve decided to mimic tls.woodgrovebank.com on my lab, and have a Windows Server 2008 R2 running 4 web sites:
- one with a "regular" RSA certificate, 2048-bits RSA public key(signed with sha1RSA), port 443
- one with an ECDH P_256 public key certificate(signed with sha256ECDSA), port 4431
- one with an ECDH P_384 public key certificate(signed with sha256ECDSA), port 4432
- one with an ECDH P_521 public key certificate(signed with sha256ECDSA), port 4433
As can be noted from above, I’ve “downgraded” the signature algorithm from sha512ECDSA to sha256ECDSA, if we were to compare my web sites with the ones from tls.woodgrovebank.com.
Also, as can be seen from above, I don’t have a web site using a DSA signed certificate, and this is because(same story as on the client) I had configured the SSL Configuration Settings group policy to make sure P_521 cipher suites are enabled on the server, and the text box on that group policy where we enter the cipher suites takes only 1023 characters or so, and I wanted to have enabled on the server as many ECDSA or RSA cipher suites as possible, which (apparently) left me no choice regarding this setting than to drop support for DSA on that server.
So on the server I’ve enabled:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384,
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P256,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P384,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384,
TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_RSA_WITH_RC4_128_SHA,
TLS_RSA_WITH_3DES_EDE_CBC_SHA
So to quickly recap, on the web sites of interest(ECDSA ones) I have the following server certificates:
Against my server, IE8 on Windows 7 speaking TLS 1.2 with the web sites, by default, will not have any problems with the:
- web site with a "regular" RSA certificate, 2048-bits RSA public key(signed with sha1RSA), port 443
- web site with an ECDH P_256 public key certificate(signed with sha256ECDSA), port 4431
- web site with an ECDH P_384 public key certificate(signed with sha256ECDSA), port 4432
But will not be able to connect to the:
- web site with an ECDH P_521 public key certificate(signed with sha256ECDSA), port 4433, because there are no P_521 ECDSA cipher suites enabled by default on the client.
We can “fix” this as we did before, say configuring the SSL Configuration Settings group policy on the client too(I’ve done that, same policy like on the server).
And now IE8’s Client Hello message should look like, note that the secp521r1 (aka NIST P-521, value “0x0091”) elliptic curve is present:
Which will make the web site with an ECDH P_521 public key certificate(signed with sha256ECDSA), port 4433 to respond this time:
As previously when I’ve configured SSL Configuration Settings group policy, same situation with the configuration of that group policy, I’ve lost the fallback mechanism on IE8, it just tries with TLS 1.2, and then it stops:
Before we attempt to use other browsers against tls.woodgrovebank.com, let’s see what else is on that server. According to http://tls.woodgrovebank.com/RFC.htm, tls.woodgrovebank.com supports the TLS User Mapping extension(which should work under TLS 1.0, TLS 1.1 and TLS 1.2).
Let’s take a look, using another basic Python script.
#!/usr/bin/python
from socket import socket
from time import sleep
raddr = "tls.woodgrovebank.com", 443
test = (
# ----> Start TLS Record Protocol
"\x16" # ContentType: Handshake
"\x03\x03" # ProtocolVersion: TLS 1.2
"\x00\x49" # Length
# ---> Start Handshake Protocol
"\x01" # HandshakeType: ClientHello
"\x00\x00\x45" # Length
"\x03\x03" # ProtocolVersion: TLS 1.2
"\x4a\xb2\x5e\x62" # Random: gmt_unix_time
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" # Random: random_bytes (28 bytes)
"\x00" # SessionID
"\x00\x02" # CipherSuites Length
"\x00\x2f" # CipherSuites
"\x01" # CompressionMethods Length
"\x00" # CompressionMethods: Null
"\x00\x1a" # Extensions Length
# --> Start Extension: signature_algorithms
"\x00\x0d" # Extension: signature_algorithms
"\x00\x10" # Extension signature_algorithms Length
"\x00\x0e" # signature algorithms Length
# -> Start signature algorithms
"\x04\x01" # sha256;rsa
"\x05\x01" # sha384;rsa
"\x02\x01" # sha1;rsa
"\x04\x03" # sha256;ecdsa
"\x05\x03" # sha384;ecdsa
"\x02\x03" # sha1;ecdsa
"\x02\x02" # sha1;dsa
# <- End signature algorithms
# <-- End Extension: signature_algorithms
# --> Start Extension: user_mapping
"\x00\x06" # Extension: user_mapping
"\x00\x02" # Extension user_mapping Length
"\x01" # user_mapping Length
# -> Start user_mapping hints
"\x40" # upn_domain_hint
# <- End user_mapping hints
# <-- End Extension: user_mapping
# <--- End Handshake Protocol
# <---- End TLS Record Layer
)
s = socket()
s.connect(raddr)
s.send(test)
reply = s.recv(1024)
s.shutdown(1)
print 'Received Reply:\n', repr(reply)
Which translates into sending(within the TLS User Mapping extension the list of supported hint types contains: UPN Domain Hint, value “0x40”):
And getting this response from the server(which indicates that the server is willing to accept user mapping data, as it included an extension of type user_mapping in the (extended) Server Hello, which contains the list of preferred hint types):
Now let’s try to access tls.woodgrovebank.com with other browsers.
Opera 10(build 1750, running on Windows 7 to keep things contiguous) is special, as like IE8 on Windows 7, it supports TLS 1.0, TLS 1.1 and TLS 1.2(see this, this and this). Opera uses it own crypto API. However, unfortunately, (as writing) Opera 10 does not have support for ECC, so it won’t be able to access tls.woodgrovebank.com web sites running on TCP ports:
- 25002
- 25003
- 24005
It is able to access tls.woodgrovebank.com web sites running on TCP ports(using TLS 1.2):
- 443
- 25000
- 24001
Opera’s configuration:
Opera’s TLS 1.2 Client Hello message, as can be noted Opera uses the TLS 1.2 signature_algorithms extension, which contains the following algorithms: sha1RSA(value “0x0201”), md5RSA(value “0x0101”) and sha1DSA(value “0x0202”):
Actually Opera has an interesting behavior, it looks like it probes to determine what protocols the server supports:
Firefox 3.5.3 also running on Windows 7(to keep things contiguous), Firefox uses NSS and not the Windows crypto api.
It supports ECC cipher suites, but from the TLS protocols, only TLS 1.0.
However, Firefox 3.5.3 “beats” IE8 on Windows 7, as, already said, it can access by default “all” the web sites from tls.woodgrovebank.com(TCP ports 443, 25000, 25001, 25002, 25003, 25004).
Let’s see what Firefox 3.5.3 sends by default within its Client Hello message, as you can notice it uses TLS 1.0 and it also uses the elliptic_curves extension indicating that it supports secp256r1(aka NIST P-256; value 23 = “0x0017”), secp384r1(aka NIST P-384; value 24 = “0x0018”) and secp521r1(aka NIST P-521; value 25 = “0x0019”) elliptic curves:
So Firefox 3.5.3 will be able to access the tls.woodgrovebank.com web site listening on TCP 25004 too:
Google Chrome 3.0.195.21 and Apple’s Safari 4.0.3, also running on Windows 7, both do not support TLS 1.1 or TLS 1.2, just TLS 1.0 from the TLS protocols.
They both seem to make use of the Windows crypto API, so they have support for ECC(installed on Windows 7).
They are able to access using TLS 1.0 the tls.woodgrovebank.com web sites running on TCP ports:
- 443
- 25000
- 25001
- 25002
- 25003
But not the one on TCP port 25004 for the same reason as IE8, they do not send the secp521r1(aka NIST P-521; value 25 = “0x0019”) elliptic curve within the the elliptic_curves extension.
Google Chrome 3.0.195.21 Client Hello message(on Windows 7):
Apple’s Safari 4.0.3 Client Hello message(on Windows 7):
Actually regarding Google Chrome 3.0.195.21(on Windows 7) I’ve observed the following behavior, if I check on IE8 only Use TLS 1.2, Google Chrome will not be able to connect to (any) secure web sites, it goes through the TCP three-way handshake, and then it FINs the connection.
On Google Chrome the only SSL setting I see is if I want to use SSL 2.0 or not.
If I check it, still cannot connect, unless I will "allow" this(SSL 2.0) also from IE 8(on IE8 only Use TLS 1.2 and Use SSL 2.0 are checked).
If I allow SSL 2.0 and TLS 1.2 on IE 8, but do not allow SSL 2.0 on Chrome, Chrome cannot connect to secure web sites.