When your browser connects to a web site protected by transport layer security of some kind (usually by accessing an
https:// URL) there's a negotiation between the two parties. Each party (browser, server) comes to the negotiation with a list of cipher suites that it is prepared to use, and the result is that one of these suites is chosen for the connection.
Recently I ran into a situation where Firefox 2.0 wasn't connecting to a site which Firefox 1.5 had no problems with. It's pretty hard to figure out which cipher suites Firefox is prepared to use from its documentation, so I decided to determine the answer directly by snooping on the negotiation part of the protocol.
Read on for method and results.
The easiest way I could find to snoop an SSL/TLS connection is to use the Wireshark protocol analyser running on the client machine. I was pleasantly surprised to find that Wireshark runs just fine in a VMware virtual machine. All you need to do is start up Wireshark and tell it to capture packets going to or from the appropriate port at the server's IP address.
Of course, Wireshark can't always tell you what's going on inside an encrypted connection; it doesn't have a magic wand. Fortunately for my purposes here, the initial cipher suite negotiation is always performed unencrypted and Wireshark is capable of breaking it down in some detail. For example, here's what Wireshark sees Firefox 1.5 sending when it opens an
Secure Socket Layer SSLv2 Record Layer: Client Hello Length: 103 Handshake Message Type: Client Hello (1) Version: TLS 1.0 (0x0301) Cipher Spec Length: 78 Session ID Length: 0 Challenge Length: 16 Cipher Specs (26 specs) Cipher Spec: SSL2_RC4_128_WITH_MD5 (0x010080) Cipher Spec: SSL2_RC2_CBC_128_CBC_WITH_MD5 (0x030080) Cipher Spec: SSL2_DES_192_EDE3_CBC_WITH_MD5 (0x0700c0) Cipher Spec: SSL2_DES_64_CBC_WITH_MD5 (0x060040) Cipher Spec: SSL2_RC4_128_EXPORT40_WITH_MD5 (0x020080) Cipher Spec: SSL2_RC2_CBC_128_CBC_WITH_MD5 (0x040080) Cipher Spec: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x000039) Cipher Spec: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x000038) Cipher Spec: TLS_RSA_WITH_AES_256_CBC_SHA (0x000035) Cipher Spec: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x000033) Cipher Spec: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x000032) Cipher Spec: TLS_RSA_WITH_RC4_128_MD5 (0x000004) Cipher Spec: TLS_RSA_WITH_RC4_128_SHA (0x000005) Cipher Spec: TLS_RSA_WITH_AES_128_CBC_SHA (0x00002f) Cipher Spec: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x000016) Cipher Spec: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x000013) Cipher Spec: SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA (0x00feff) Cipher Spec: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x00000a) Cipher Spec: TLS_DHE_RSA_WITH_DES_CBC_SHA (0x000015) Cipher Spec: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x000012) Cipher Spec: SSL_RSA_FIPS_WITH_DES_CBC_SHA (0x00fefe) Cipher Spec: TLS_RSA_WITH_DES_CBC_SHA (0x000009) Cipher Spec: TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x000064) Cipher Spec: TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x000062) Cipher Spec: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x000003) Cipher Spec: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x000006) Challenge
For the record, the above is from a CentOS 5 system, although I suspect that doesn't matter.
By comparison, the following comes from Firefox 2.0 under Fedora 7:
Secure Socket Layer TLSv1 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 102 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 98 Version: TLS 1.0 (0x0301) Random gmt_unix_time: Feb 6, 1970 14:03:37.000000000 random_bytes: 344D04196CDE0D05A480714440E227729CFD6F94F9AF9689... Session ID Length: 0 Cipher Suites Length: 24 Cipher Suites (12 suites) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004) Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) Cipher Suite: SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA (0xfeff) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Extensions Length: 33 Extension: server_name Type: server_name (0x0000) Length: 29 Data (29 bytes)
It's pretty obvious that Firefox 2.0 has tightened things up in several ways. Most obviously, there are far fewer cipher suites offered to the server by Firefox 2.0. In particular, the following are missing:
SSL2_RC4_128_WITH_MD5 SSL2_RC2_CBC_128_CBC_WITH_MD5 SSL2_DES_192_EDE3_CBC_WITH_MD5 SSL2_DES_64_CBC_WITH_MD5 SSL2_RC4_128_EXPORT40_WITH_MD5 SSL2_RC2_CBC_128_CBC_WITH_MD5 TLS_DHE_RSA_WITH_DES_CBC_SHA TLS_DHE_DSS_WITH_DES_CBC_SHA SSL_RSA_FIPS_WITH_DES_CBC_SHA TLS_RSA_WITH_DES_CBC_SHA TLS_RSA_EXPORT1024_WITH_RC4_56_SHA TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA TLS_RSA_EXPORT_WITH_RC4_40_MD5 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
This is by default; it turns out that if you dig around enough you can turn some of these back on again. You might not want to, though, as they have been removed from the default configuration for good reason:
Cipher suites requiring the SSL V2 protocol have been removed because of the many known issues with the protocol. This accounts for the six
SSL2_ removals: SSL V3 and TLS V1 have been around for roughly a decade, so supporting the older broken protocol seems unnecessary.
_EXPORT_ cipher suites have been removed. These suites use very weak cryptography by modern standards; as the US regulations that required their implementation were loosened some years ago, it again seems unhelpful to continue supporting the weaker systems.
Four cipher suites making use of the original DES standard (albeit in its "full strength" form with a 56-bit key) have been removed.
I don't see any real reason to object to any of the above; if you support connections using weak ciphers, you're giving people an unjustified level of assurance about the security of their communications. In that sense, weak cryptography is worse than none at all.