« Improved passive SSL fingerprinting in sslhaf | Main | SSL Labs update increases security requirements »

Large-scale passive SSL monitoring at ICSI

November 12, 2012

The International Computer Science Institute (ICSI) recently announced a new certificate notary project. Although I find the notary aspect of the project interesting, I think that their work is much more important because of the potential of their approach, which is based on large-scale passive monitoring of SSL connections. In the last couple of years I spent a lot of time looking at the server-side aspect of SSL (most recently, in the SSL Pulse project), but there's a large gap in our understanding when it comes to client-side capabilities, and actual real-life usage. The gap can be explained by ICSI's data.

Sadly, ICSI is unable to share their data because of various privacy concerns. However, they can still mine the data themselves. I decided to put together a list of unanswered SSL usage questions, as a way of contributing to the effort.

Focusing on client capabilities is a good way to start. Some of the most interesting attributes to track might be:

  • Highest TLS version
  • Cipher suites (and their order)
  • TLS extensions
  • Compression methods
  • BEAST mitigation
  • SNI (virtual SSL hosting)
  • Secure renegotiation (via extension or SCSV)
  • Session ticket support
  • Request for OCSP stapling
  • SPDY support (via the NPN extension)

The most exciting aspect of the project is that it might be able to finally give us the answer to the effective security of SSL. Some key data points include:

  • Negotiated protocol version
  • Negotiated cipher suite/strength
  • Was the suite actively selected by the server
  • Authentication strength (certificate key size)
  • DH params/strength (for applicable cipher suites)
  • Compression usage
  • Session resumption status (tracked via either mechanism)
  • Seen stapled OCSP response
  • Server certificate information
    • Key size
    • Signature algorithm
    • Is it expired?
    • Is it self-signed?
  • Certificate chain correctness
  • Is the trust root a well-known CA?
  • Vulnerabilities:
    • Renegotiation (do both sides support secure renegotiation)
    • BEAST (no browser mitigation and a CBC suite using TLS 1.0 or earlier)
    • CRIME (use of TLS compression for the connection)