Mozilla/Microsoft Consider Accelerating Timetable for Blocking SHA-1 Certs

In a recent blog post, Microsoft said it may follow Mozilla in accelerating its timetable for blocking SHA-1 signed TLS certs.

Mozilla, Microsoft and Google have all announced plans to block SHA-1 signed certs beginning in 2017, but the cost and time to create SHA-1 collisions just keeps plunging.

In light of recent advances in attacks on the SHA-1 algorithm, we are now considering an accelerated timeline to deprecate SHA-1 signed TLS certificates as early as June 2016.

In an October blog post, Mozilla said it was considering a July 1, 2016 date for blocking SHA-1 signed certs,

We are re-evaluating when we should start rejecting all SHA-1 SSL certificates (regardless of when they were issued).  As we said before, the current plan is to make this change on January 1, 2017.  However, in light of recent attacks on SHA-1, we are also considering the feasibility of having a cut-off date as early as July 1, 2016.

Both Mozilla and Microsoft are spooked by this report that found,

Concretely, we estimate the SHA-1 collision cost today (i.e., Fall 2015) between 75K$ and 120K$ renting Amazon EC2 cloud computing over a few months. By contrast, security expert Bruce Schneier previously projected (based on calculations from Jesse Walker) the SHA-1 collision cost to be ~173K$ by 2018. Note that he deems this to be within the resources of a criminal syndicate. Large corporations and governments may possess even greater resources and may not require Amazon EC2. Microsoft, Google and Mozilla have all announced that their respective browsers will stop accepting SHA-1 based SSL certificates by 2017 (and that SHA-1-based certificates should not be issued after 2015). In conclusion, our estimates imply SHA-1 collisions to be now (Fall 2015) within the resources of criminal syndicates, two years earlier than previously expected and one year before SHA-1 will be marked as unsafe in modern Internet browsers. This motivates our recommendations for industry standard SHA-1 to be retracted as soon as possible. With our new cost projections in mind, we strongly and urgently recommend against a recent proposal to extend the issuance of SHA-1 certificates with a year in the CAB/forum (discussion closes October 9 2015, vote closes October 16).


Peter Eckersley’s Presentation on Let’s Encrypt at CCCamp15

Peter Eckersley gave an impressive presentation about the Let’s Encrypt initiative at CCCamp15.

Let’s Encrypt is mainly known for it’s plan to offer free SSL certificates, which is cool, but the most interesting part of Eckersley’s presentation starts about 25 minutes in where he discusses how the initiative plans to address issues surrounding vulnerabilities related to the Certificate Authority system itself.

The only thing I see personally that I wish Let’s Encrypt supported right out of the gate is Wildcard Certs, but Eckersley indicates in the Q&A session that they will be looking into things like Wildcard Certs after they’re certain the basic functionality of their CA is rock solid.


Firefox 3 and Self-Signed SSL Certificates

Firefox 3 changed how it handles self-signed SSL certificates — it gives users a big scary full-page warning that “The certificate is not trusted because it is self signed.”  You can add an exception for sites using self-signed certificates, but Firefox will warn you that ““Legitimate sites will not ask you to do this.”

The change has made some people unhappy, including Nat Tuck Thu who writes,

Now, it’s an interesting question as to exactly what the user interface should show for a self-signed website. Obviously it shouldn’t show a green address bar like the new (extra high price, major corporation only) EV certificates. But there is absolutely no excuse for it to be significanly less inviting to a normal user than an unencrypted site.

This is really an issue of the basic principles of internet openness. Everyone has equal access to the features of HTTP or SSH, there’s no reason why there should be artifical constraints on access to HTTPS. But that’s exactly what the Firefox SSL behavior does.

In response to various critics of the Firefox approach, Johnathan Nightingale makes a persuasive case in favor of Firefox’s handling of self-signed certificates,

The question isn’t whether you trust your buddy’s webmail – of course you do, your buddy’s a good guy – the question is whether that’s even his server at all.  With a CA-signed cert, we trust that it is – CAs are required to maintain third party audits of their issuing criteria, and Mozilla requires verification of domain ownership to be one of them.

With a self-signed certificate, we don’t know whether to trust it or not.  It’s not that these certificates are implicitly evil, it’s that they are implicitly untrusted – no one has vouched for them, so we ask the user.  There is language in the dialogs that talks about how legitimate banks and other public web sites shouldn’t use them, because it is in precisely those cases that we want novice users to feel some trepidation, and exercise some caution. There is a real possibility there, hopefully slim, that they are being attacked, and there is no other way for us to know.

On the other hand – if you visit a server which does have a legitimate need for a self-signed certificate, Firefox basically asks you to say “I know you don’t trust this certificate, but I do.”  You add an exception, and assuming you make it permanent, Firefox will begin trusting that specific cert to identify that specific site.  What’s more, you’ll now get the same protection as a CA signed cert – if you are attacked and someone tries to insert themselves between you and your webmail, the warning will come up again.

One of the complaints I’ve seen in a number of forums is that with a CA signed cert you’re paying potentially hundreds of dollars, but it turns out there are free cert provides. StartSSL, for example, has a free cert, for example. They verify domain ownership by requiring you to upload an arbitrary file to the website you want the cert for.