Comment by pilif | Hacker News Reader

Comment by pilif | Hacker News Reader

Let's say CAs continue to issue SHA-1 certificates and fail to do the recommended Legacy Validation but just issue the certs. Let's further assume that clients which still get updates are updated to not accept SHA-1 at all any more.

Wouldn't that be enough already? Newer clients wouldn't be able to access sites that exclusively serve SHA-1 certificates, so that's the loss of the site-owner to only and unconditionally present the SHA-1 cert. IMHO no special handling on the side of the CA is required here.

I see no potential for a downgrade attack because a current client would only support SHA-2 anyways, so trying to MITM the connection to pretend the client supporting only SHA-1 in order to induce the server to present the SHA-1 cert would only lead the the up-to-date client to reject the connection.

However, if the site presents a SHA-2 cert where possible, falling back to the SHA-1 cert, then old and unsupported clients would still be able to access the site. Yes, the security would be reduced and it would certainly not be sufficient to protect against state-sponsored attacks, but it's still way better in protecting against FireSheep-like attacks done by individuals.

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.

I was proposing simply restricting to manual issuance, which mitigates the risks and discourages the use of such certificates.

Reply on news.ycombinator.com