RSA+SHA1 web compatibility regression

[Darkspirit]

#88 and rustls/rustls#207 removed RSA+SHA1 which seemed the right thing to do, but apparently made some web sites unaccessible.

Problem

With Servo (both with rustls and with Debian's default OpenSSL config which defines DEFAULT@SECLEVEL=2) I am not able to connect to the website of Germany's first public TV channel. Chrome and Firefox connect without problem.

cargo install rustls-mio --example tlsclient --git https://github.com/ctz/rustls/ --rev d132d48a236a212b1c79ca5b5182fb522007050c -f; tlsclient --http --protover="1.2" www.daserste.de

TLS error: PeerMisbehavedError("received unadvertised sig scheme RSA_PKCS1_SHA1")
Connection closed

openssl s_client -connect www.daserste.de:443 -tls1_2 -cipher DEFAULT@SECLEVEL=2

139846699320512:error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature type:../ssl/t1_lib.c:1110:

openssl s_client -connect www.daserste.de:443 -tls1_2 -cipher DEFAULT@SECLEVEL=1

Peer signing digest: SHA1
Peer signature type: RSA

Chrome Dev > Devtools > Security

The server signature uses SHA-1, which is obsolete. Enable a SHA-2 signature algorithm instead. (Note this is different from the signature in the certificate.)

Questions

• Should RSA+SHA1 support be restored in rustls and webpki?
• Could you ask Google folks about telemetry on how widespread this still is?

See also

• Remove SHA-1 support #21
• get.adobe.com results in wrong signature type openssl/openssl#7126 (get.adobe.com is still broken/SHA1 after a year)
• https://bugs.chromium.org/p/chromium/issues/detail?id=655318#c10

That said, if F5 picks SHA-1 on ANY, that's a bug in F5. The client sends a list of signature/hash algorithms, so F5 should process that and pick a setting algorithm both sides agreed on.

Are you up-to-date on F5 firmware? We've been in contact with them about similar issues with RSA (we can't get rid of SHA-1 in RSA just yet because it's much much more widespread).

• https://bugs.chromium.org/p/chromium/issues/detail?id=658905
• Please Show ServerKeyExchange signed_params Hash Function ssllabs/ssllabs-scan#465
• Add peer signing digest algorithm to the checks hardenize/hardenize-public#48

[briansmith]

I am open to solutions but I'd like to figure out one that doesn't require Rustls and friends to accept SHA-1 signatures for every host.

We got along fine for 10 months so I'm thinking this isn't very common. Thus, I would encourage people to work on the advocacy aspect, i.e. helping https://www.daserste.de/ and related sites fix their configuration. This is something I can't reasonably do but something the community around this project could do. We have succeeded in such advocacy in the past, especially pretty recently.

At the webpki level, we can of course add SHA-1 back if it would be used by somebody. But would Rustls actually make use of it if we added it back?

[ctz]

If we were to add this back, I think it'd really only be in the context of this issue. In which case we could add it back only for verify_signature use, not certificate chain building? That's a bit of a bodge, but seems like the least worse thing to do.

Though, I think in this case I prefer to do nothing. I'd likely change my mind if there was some more data showing a prevalence of servers with this bug.

[Darkspirit]

• I've emailed Adobe via PSIRT@adobe.com, hopefully it will find its way... DasErste.de replied their technicians have been informed.
• Filed Bug 1600449 - Log a warning message when a site uses RSA-PKCS1-SHA1 signature scheme.
• Filed Bug 1600437 - Consider removing ECDSA_SHA1 signature algorithm.
• There is a draft underway:
  https://bugs.chromium.org/p/chromium/issues/detail?id=658905#c3

  [...]
  But, yes, I would love to plug this hole.
  If you run into sites with problems, I'd recommend contacting them. I started poking servers a few years ago and it was mostly buggy older TLS load balancer products which failed to implement TLS 1.2, as well as a bug in older OpenSSLs. (At one point I knew the tests to distinguish the various bugs, but alas I've long since forgotten them and would need to figure it out again.) If you need something immediate to point to, the TLSWG recently adopted a draft to deprecate these: https://tools.ietf.org/html/draft-ietf-tls-md5-sha1-deprecate-00

[Darkspirit]

https://sha-mbles.github.io/

We have contacted the OpenSSL developers on December 14th. They are considering disabling SHA-1 at security level 1 (defined as 80-bit security) after our attack. Since security level 1 is the default configuration, this would prevent SHA-1 usage for certificates, and for handshake signatures. Debian Linux had previously set the default configuration to security level 2 (defined as 112-bit security) in the latest release (Debian Buster); this already prevents dangerous usage of SHA-1.