ServerTastic Blog

Updates from the world of ServerTastic

Stripping OCSP From Chrome Will Not Improve Browser Security

Symantec applauds Adam Langley’s resolve to increase consumer safety on the web, however, his proposal to remove OCSP and CRLs in a future release of the Chrome browser is misguided and could potentially have dangerous implications. Mr. Langley argues that OCSP and CRLs do not work when needed, giving the example of a captive portal that requires you to sign in to an HTTPS site while blocking traffic to all other sites. This is a corner case that happens very infrequently. We argue that one shouldn’t discard OCSP and CRLs because they don’t work in a tiny fraction of cases.

Langley also expresses concern that the CA may experience downtime. Symantec has provided CRLs and OCSP responses with 100% uptime for at least the past 10 years. We serve over 3.5 billion OCSP lookups every day, allowing browsers to reliably receive real-time validation of SSL certificates. Rather than letting CAs off the hook, Symantec believes that CAs should be required to maintain high-availability certificate  status checking services, in line with the work that the CA/Browser Forum has done to raise the bar for certificate issuers.

His proposal to have the browser maintain a list of revoked certificates turns Google into a single point of failure, which Langley himself agrees is bad engineering practice. 

In fact, the real issue at hand lies in the ‘soft fail’ protocol currently used by browsers. When an error occurs in CRL or OCSP checking, browsers silently allow the user to proceed to the website, presumably to maintain the quality of the user experience. This client implementation flaw allows web sessions to continue without properly vetting the validity of the SSL certificate, sacrificing security for incremental performance improvement.

Symantec disagrees with Adam Langley’s decision to strip OCSP and CRLs from future revs of Google Chrome, as it will serve as a security downgrade. We look forward to discussing this topic with our peers in the CA- Browser Forum in the coming weeks and to working collaboratively with the industry to develop a solution that works best for consumers and businesses.

Most users do not realise that the browser does a realtime check to see if an SSL certificate is valid. This is one of the reasons that you have to renew your SSL certificate like a domain. Maintaining the OCSP database costs a few $$.

However is removing this check in Chrome a backwards step for security? Let us know what you think.

Web Browser Security User Interfaces: Hard to Get Right and Increasingly Inconsistent

Browser-ssl-ui-comparison1

This interesting and useful post on Web Browser Security User Interfaces: Hard to Get Right and Increasingly Inconsistent by Steve Schultze highlights the growing differences between how browsers interpret the varying security aspects of SSL certificates. I highly recommend reading the article to get a good understand of how your website will look in all the different browsers depending on the type of SSL certificate you use.

Despite the CAB forum‘s existence as a way of unifying the SSL/browser experience each browsers seems to have its own interpretation of how these “standards” should be implemented.

Earlier I posted about how Firefox 4.0 no longer had the padlock symbol on secure websites. The padlock symbol has been a long standing and instantly recognised way of highlighting secure websites. But, as suggested by Firefox, has this lead to a false sense of security?

Green is the emerging colour for websites using Extended Validation SSL certificates. But there is also wildy different interpretations of how this should be implemented. IE8+ has implemented an entire green address bar while FireFox and Chrome have opted for just the company name in green. Safari 4 implementation is even less obvious with just the letters in green.

What is your view on the different browser implementations? Was Firefox right to drop the padlock symbol?