[cabfpub] TLS client data

[Eric Mill]

Thanks for publishing this, Peter. I converted the file to a CSV, for those
who wish to open it in Excel or something:
https://s3.amazonaws.com/konklone-public/lv/ua-capabilities.csv.zip

The Python script I used to do the conversion is here:
https://gist.github.com/konklone/d095fb7224716c9212e6

Also, people may find the IANA mapping of TLS extension values to names to
be helpful:
http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml

If it's helpful, I can look at adapting my script to break apart the
flags/extensions field into their own cells for filtering
per-flag/extension.

-- Eric

On Wed, Dec 23, 2015 at 5:11 PM, Peter Bowen <pzb at amzn.com> wrote:

> 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
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>



-- 
konklone.com | @konklone <https://twitter.com/konklone>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151223/3d9ae517/attachment.html