crypto/x509: reject SHA-1 signatures in Verify

[FiloSottile]

SHA-1 is weak: a SHA-1 collision was demonstrated and estimated to cost around $50k. https://shattered.io

Accepting SHA-1 signed certificates is a security issue, and lets attackers mount collision attacks if the CA is still signing SHA-1 certificates. crypto/x509 already rejects outright any MD5 signatures for the same reason.

The WebPKI has banned SHA-1 certificates for years now, and crypto/x509 targets a profile compatible with the WebPKI.

I propose we announce in Go 1.17 that we'll remove support in Go 1.18, and provide a GODEBUG opt-out until Go 1.19.

[FiloSottile]

It doesn't look like the opt-in GODEBUG phase has been useful in the past, and SHA-1 is already severely broken. Let's go straight to the GODEBUG opt-out phase for Go 1.17, assuming people test the new release in canaries or similar anyway.

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[ianlancetaylor]

@Prajwal-Koirala See https://golang.org/wiki/NoPlusOne. Thanks.

[rsc]

How many of the ancient servers being discussed in #45428 are serving SHA-1 signatures?

[FiloSottile]

SHA-1 in crypto/x509 is unrelated to crypto/tls, except to the extent that if you're running a legacy stack you're more likely to have both components be out of date. You can serve a SHA-1 certificate over TLS 1.3, if you felt like it.

There are no publicly trusted SHA-1 certificates anymore, so we pretty much have no numbers about them. (Well, we do, and they say zero, but they don't capture internal deployments.) Anyone using them is doing it with their own managed CA.