
SHA-1 Certificates: A History of Hard Choices - tptacek
https://medium.com/@sleevi_/a-history-of-hard-choices-c1e1cc9bb089#.grsxeuoco
======
pilif
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.

~~~
Lukasa
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.

~~~
CJefferson
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.

~~~
Lukasa
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.

~~~
saurik
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).

------
wtbob
> The responses are largely tepid, with the conclusion seeming to be that PKIX
> feels it “can afford to wait until the very last minute, i.e. when SHA1 is
> actually broken, rather than to upgrade to some fix like SHA256 before SHA1
> is broken.”

That right there tells you everything you need to know about XPKI and the CA
infrastructure. It's sad that a decade before the event above took place, we
had a reasoned, well-thought-out alternative to XPKI, but because no-one cared
it went absolutely nowhere.

I really, really hope that after these lost two decades the industry revisits
and updates the ideas behind SPKI[1] and finally figures out how to actually
secure Internet communications. Can't say that I'm holding my breath though.

[1]
[http://world.std.com/~cme/html/spki.html](http://world.std.com/~cme/html/spki.html)

~~~
tptacek
I also find it upsetting, but this is a phenomenon not limited to PKIX-world;
for instance: the DNSSEC root keys, which nobody in the real world even relies
on yet, are RSA-1024.

~~~
xorcist
That's part of the story. The root keys are RSA-2048, but the intermediary
zone signing keys for the root are RSA-1024. The latter keys are changed every
third month. So, while there is pressing need to move to larger key sizes, the
short validity tends to lessen the impact somewhat.

There were some concerns that the larger keys could cause issues with some
network equipment, but it looks like those concerns were overblown. Network
engineers are a fairly conservative bunch and, perhaps contrary to your
expectations, there are real systems in the real world that would break if the
root zone broke. These systems tend not to be web, so they might not be as
visible to an end user perhaps.

~~~
tptacek
"Conservative" is not the word I would use about this decision.

