Improving Revocation in the SSL/TLS jungle - Firefox Approach
-
Upload
mohammed-almeshekah -
Category
Technology
-
view
1.118 -
download
0
Transcript of Improving Revocation in the SSL/TLS jungle - Firefox Approach
Improving Revocation In The Ssl/Tls Jungle
By:
Mohammed Almeshekah
Security Engineering Team
!
August 1st, 2013
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).
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/
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).
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!
The Ssl/Tls Jungle - What Is Revoked?
Why are certificate being revoked?
!
!
!
!
!
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?
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.
Revocation Mechanisms
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?
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.
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.
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.
Thanks
Presentation available at:
www.meshekah.com
Personal Email: [email protected] - Twitter: @meshekah