[openssl-users] Rejecting SHA-1 certificates

Michael Wojcik Michael.Wojcik at microfocus.com
Mon Jul 10 23:37:41 UTC 2017


> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Viktor Dukhovni
> Sent: Monday, July 10, 2017 13:24
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Rejecting SHA-1 certificates
> 
> On Mon, Jul 10, 2017 at 08:19:11PM +0200, Niklas Keller wrote:
> 
> > > What's your threat model, and how does it justify this effort?
> >
> > The same as for browsers I guess. Could you explain why browsers and
> Java
> > disable SHA1, but it's not worth for me doing so?
> 
> The browsers and Java do this because they can (they control the
> underlying libraries) and in order to prod the CAs into action,
> and to force server operators to move to SHA2.

That, and PR. Google has Chrome deprecate SHA-1, so they can wave the security flag. Then everyone else has to follow suit to prove they're equally concerned with security.

Security is always about economics. Deprecating SHA-1 is cheap for the major browsers; there's a small development cost and some irritation to users, but if all the major browsers do it, then the latter becomes an externality - it's not going to cost the browsers any market share. And while it doesn't have a lot of value, as Viktor pointed out, it does prod CAs and server owners to update now, before there's any real threat. So there's some return - enough to justify their investment.

For the vast majority of OpenSSL-based applications, the higher cost is not justified by the lower return. We've already noted why the cost is higher. The return is lower because most OpenSSL-based applications are much less prominent than browsers, so fewer people will notice (thus there's less PR and industry-prodding benefit) and less risk of some wildly well-resourced attacker trying to forge a certificate (assuming that's even feasible, given the constraints of the format).

More generally, making security decisions without understanding your threat model and at least estimating the cost/benefit ratio is a Bad Thing. It's stabbing in the dark. And it's critical to include the opportunity cost - could those resources be put to better use, such as finding and fixing more realistic vulnerabilities?

Michael Wojcik 
Distinguished Engineer, Micro Focus 



More information about the openssl-users mailing list