Trust is a very crucial aspect of our daily lives when navigating the web. Currently, digital certificates are the main way of establishing server's identities in the Internet, Trust is dynamic property that can change over time and browsers should adapt very quickly to enforce the latest trust status of a "secure" server when establishing secure connections. However, most of the current revocation models have a performance impact and new mechanisms revocation models need to be adapted. In this talk, Mohammed, will discuss the current status of SSL certificates revocation in Firefox. He will highlight the work he has done during his time at mozilla in analyzing the SSL jungle of the top million sites on the internet and building the CRLSet revocation mechanism in firefox.

1. Improving Revocation In The
Ssl/Tls Jungle
By:
Mohammed Almeshekah
Security Engineering Team
!
August 1st, 2013

2. Secure Connections (Ssl/Tls) &
Revocation
When Firefox connects to a secure (i.e. https) server, a certificate
must be presented to establish the identity of the server.
!
The certificate chain must be valid (not revoked) at all times. Two
traditional mechanisms exist:
• CRL (Certificate Revocation List).
• OCSP (Online Certificate Status Protocol).

3. What Is Done Currently In Firefox
Checking (only the end entity) CRL and OCSP -> No response ->
assume it is trusted!?
Shipping a new release when major compromise occurs:
• https://blog.mozilla.org/security/2011/09/02/diginotar-removal-follow-up/

4. What Did I Do @ Mozilla
Building a tool to analyze the SSL/TLS Jungle of the Alexa top 1
million sites (can easily be expanded to analyze the whole IPv4
address range)
!
Building a tool to analyze the revocation dynamics of the Alexa top 1
million.
!
Implement a better approach for certificate revocation in Firefox
(Preloaded and Dynamic CRLSets).

5. Crls And Ocsps In The Jungle
These certificates pointed to 1,774 CRLs and 1,292 authority (OCSP) servers.
CRLs:
• Only 987 CRL servers responded [about (~1/2) are dead].
• Total size of all CRLs is (~98 MB) [average is ~100 KB].
• ~2.65 millions revoked certificates.
OCSPs:
• Performance concerns (OCSP for every cert in the chain).
• CAs learn your browsing habits (privacy concerns).
• Response takes about 200ms in the US!

6. The Ssl/Tls Jungle - What Is Revoked?
Why are certificate being revoked?
!
!
!
!
!

7. The Ssl/Tls Jungle, Contd.
Clearly we are in a bad shape:
• Revocation servers are not responding.
• A LOT of certificates being revoked.
• CRLs have an overage overhead of 100K (FFOS!).
• OCSP has privacy concerns, SSL/TLS connections have to ping a CA
server.
“Performance vs. Security vs. Privacy” -> Can we do something?

8. New Revocation Mechanisms
We need more than one mechanism:
• We cannot bundle 2.65 million revocation information in Firefox (that is
only for the Alexa top 1 million).
!
Currently two projects are in progress:
• OCSP Stapling [and must-staple] (by David Keeler) - Stapling is in
Nightly now.
‣ https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/
• CRLSet.

9. Revocation Mechanisms

10. Crlset
Firefox will be having two CRLSets:
• Preloaded CRLSet - revoked certificates that come built-in the
browser.
• Dynamic CRLSet - seamlessly update the revocation information
pushing the information to the browsers without having to push new
releases.
What to include in the CRLSet?

11. What To Revoke?
We can distinguish two major categories:
• Revocations due to CAs mistakes (e.g mis-issuance, CA compromise, ..)
• Revocations due to server operators mistakes (server key compromise,
etc).
Currently the Preloaded CRLSet is based on the revocation reasons
in the actual CRLs.

12. Done & In Progress
The tools are already uploaded in Github:
• https://github.com/meshekah/SSL_Certs
CRLSet:
• Bug 886471.
• Preloaded is almost done (final testing and reviews).
• Dynamic - most of the logic is done, need to bundle the XHR request
and download the delta file.

13. Final Thoughts
SSL/TLS and trust is a BIGger mess than I thought.
It is very interesting to work on cutting edge ideas that have never
been implemented before and set the standards. Data is GOLD in
these cases.
Special thanks to:
• Sid Stamm - my great manager.
• Camilo Viecco - my awesome advisor.
• Brian Smith.

14. Thanks
Presentation available at:
www.meshekah.com
Personal Email: meshekah@gmail.com - Twitter: @meshekah