[cabfpub] TLS client data

Peter Bowen pzb at amzn.com
Wed Dec 23 15:11:47 MST 2015


In any discussion of setting policy, it is important to have data that can be used to understand possible impacts. A few months ago, I was able to work with the owners of some websites to help collect data on TLS capabilities of clients connecting to the website.  This data was collected by having the site owners include a subresource in their site (e.g. image or javascript) that was loaded from a special server that logged TLS ClientHello messages as part of the access log.  It also logged HTTP layer information such as the User-Agent header.

The full data is described below, but one very notable result is that many connections were seen where the ClientHello did not match the browser capability.  While it is hard to know exactly why, I assume it is because some application or appliance is proxying the TLS connection.  For example, 39593 connections were observed where the user agent was listed as Chrome 45 on Windows 7 (or Server 2008 R2) but where no SHA-2 or AEAD algorithms were offered.  On the other hand, only 0.55% of IE/Safari connections from NT 5 (XP) sent a handshake indicating a direct connection; the rest went via a TLS proxy that upgraded their TLS capabilities.

The logs were processed to generate a summary of the client connections, including the User-Agent header value and a fingerprint of the ClientHello.  The fingerprint contains several flags and then a list of TLS extensions included, in the order they appear in the ClientHello message. The possible flags are:
sha2_mac: At least one offered cipher suite uses a SHA256 or SHA384 MAC
aead: At least one offered cipher suite uses GCM or CCM or Poly1305
des: At least one offered cipher suite uses single DES
export: At least one offered cipher suite uses reduced strength cryptography that was considered export-grade long ago
sha2_hashalg: The Signature Algorithms extension was sent and contained at least one of SHA-256, SHA-384, or SHA-512
hello_v2: the ClientHello was in SSLv2 compatible format rather than SSLv3/TLS format
“v” plus two numbers: the maximum supported protocol version (3.3 => TLS 1.2, 3.1 => TLS 1.0, 3.0 => SSLv3)

The full data is available from https://s3-us-west-2.amazonaws.com/pzb-public-files/ua-capabilities.zip contains the results.  The text file uses the tab character as a delimiter between the three fields and represents more than 210 million data points.

I hope that anyone proposing changes to CA/Browser Forum Guidelines can share similar details to help everyone understand the impact of the proposals.

Thanks,
Peter


More information about the Public mailing list