Comment by Lukasa | Hacker News Reader

Comment by Lukasa | Hacker News Reader

Parent Full thread

You have to read the follow-up post to get a good description of why this won't work, but let me try.

The problem is that most clients currently are not able to build up multiple trust chains. They hand OpenSSL the certificates the remote server gave them, a pile of root certs, and say "tell me if you can build a trust chain". To remove SHA1 support, they'd have to inspect the returned trust chain and check whether any certs have SHA1 signatures. If they do, you'd fail outright, even though there may have been a perfectly good SHA2-only path available that OpenSSL didn't take, because there's no way to tell OpenSSL "try again but don't use this cert".

This means that we're telling the 97% of users with "modern" clients to force all TLS stacks to add support for new path building logic with arbitrary certificate avoidance in order to avoid the pain of the 3% of users who didn't get upgrades.

Note that I said "OpenSSL" here, but it actually applies to a wide range of TLS stacks: OpenSSL is just one of the more widely deployed ones.

On the other hand, upgrading that 3% of users often just isn't possible, while newer users who are upgrading to disable SHA1 support, can get this extra functionality at the same time.

Also, this feels like the kind of thing which might happen again -- worth trying to get backwards compatibility right.

Oh if only that were possible. However, many people are using older OpenSSLs with no route to upgrading. For example, Ubuntu 14.04 is using OpenSSL 1.0.1 currently, and will not upgrade to any later release of OpenSSL. It's unlikely to get backported to earlier releases because it fundamentally changes the logic and API of that OpenSSL release (by requiring a whole slew of extra functions that affect cert chain building). This would mean anyone not using a bleeding-edge system is caught in this situation where they can't upgrade.

It's definitely an interesting idea to allow constraints to be set on what certificates can be used during chain construction, but the scope of the problem is very large: there are lots of fields in an X509 certificate, many with complex values that complex filtering may want to be done on. In principle this can be done using callbacks from OpenSSL, but because of the potential up-and-down nature of building these trees there will be a substantial amount of complexity in place.

And the reality is that backward compatibility is already right. OpenSSL, today, is backward compatible with SHA1 certs. The problem here is forward compatibility: making older SSL stacks meet the security requirements of the modern day, many years after they were written. That's hard, and may actually be impossible.

It would break either API nor ABI to make "disallow SHA-1 certificates" a setting that could be configured globally by the system administrator (and it could even be controlled by an environment variable to support it per-process).

So the TL;DR would be "because we don't want to make changes on current clients, we break compatibility for old clients where we cannot make changes"?

Seems like this comment is based on a bad assumption. A lot of what you call "current clients" won't be updated either--they're new enough to not be stuck with SHA-1, but that doesn't mean they're getting updated anymore.

This is exactly correct.

The answer is that we should build better routing into OpenSSL - and all the other PKI-validating products. It's complex and complicated, but if you only have a very narrow and particular purpose (e.g. just care about TLS), then you can get away with it with rather a little amount of code, as Mozilla's mozilla::pkix shows - https://blog.mozilla.org/security/2014/04/24/exciting-update...

But even if we were to change all systems tomorrow, that affects only the upper 10% or, to be generous, 25% of PKI clients (nb: numbers pulled out of my ass, but it's an experienced ass). We still have a LONG tail of systems running OpenSSL, earlier versions of Windows, or any number of custom solutions, and they support SHA-256 but won't ever be updated again. So stopping SHA-1 actually protects them, and is the only thing that CAN possibly protect them, and that's why LV is such a hard trade-off: we give up the protections for a large chunk of users, in order to regain access to a small group.

And that's ignoring that the data quantifying the size of the small group, or _why_ the small group exists (to see if there are other levers or alternatives than "replace device" and/or "keep issuing SHA-1" exist. Luckily, Jan 1 isn't going to be some SHApocolypse - 39 month certs issued on Dec 31 2015 will remain valid well into 2019, so there's time to have a reasoned, data-driven debate about "old-old" clients, "new-old" clients, and "new-new" clients.

Reply on news.ycombinator.com