The following revision refers to this bug:
  https://boringssl.googlesource.com/boringssl.git/+/3ef7697ed30f28367395a5aafb57a12a19906d96

commit 3ef7697ed30f28367395a5aafb57a12a19906d96
Author: David Benjamin <davidben@google.com>
Date: Mon Oct 17 21:59:54 2016

Don't accept {sha1, ecdsa} and {sha512, ecdsa}.

{sha1, ecdsa} is virtually nonexistent. {sha512, ecdsa} is pointless
when we only accept P-256 and P-384. See Chromium Intent thread here:

https://groups.google.com/a/chromium.org/d/msg/blink-dev/kWwLfeIQIBM/9chGZ40TCQAJ

This tweaks the signature algorithm logic slightly so that sign and
verify preferences are separate.

BUG= chromium:655318 

Change-Id: I1097332600dcaa38e62e4dffa0194fb734c6df3f
Reviewed-on: https://boringssl-review.googlesource.com/11621
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>

[modify] https://crrev.com/3ef7697ed30f28367395a5aafb57a12a19906d96/ssl/handshake_server.c
[modify] https://crrev.com/3ef7697ed30f28367395a5aafb57a12a19906d96/ssl/internal.h
[modify] https://crrev.com/3ef7697ed30f28367395a5aafb57a12a19906d96/ssl/ssl_test.cc
[modify] https://crrev.com/3ef7697ed30f28367395a5aafb57a12a19906d96/ssl/t1_lib.c
[modify] https://crrev.com/3ef7697ed30f28367395a5aafb57a12a19906d96/ssl/test/runner/runner.go
[modify] https://crrev.com/3ef7697ed30f28367395a5aafb57a12a19906d96/ssl/tls13_server.c

Be advised that this will break TLS v1.2 connections to IIS servers using certs with SHA-512 signature algorithms, as IIS will simply abort the connection:

https://groups.google.com/a/tagpma.org/forum/#!topic/tagpma-general/_NbjhvKJ4qI/discussion

The result is an ERR_CONNECTION_RESET on Chrome v56. The previous v55 still works fine.

The underlying OS for the client does not matter. For the server we tested with IIS on Windows Server 2012 R2.

What curve are these certificates using? We haven't advertised P-521 for a long long time, and using SHA-512 with P-384 or P-256 is pointless. The hash gets truncated to the curve's size anyway.

(Mismatching curve/hash is also a little questionable cryptographically as ECDSA does not include a distinguisher for the hash algorithm used.)

These certificates are using secp384r1 (P-384) so I agree, this can be considered a configuration mistake. However, it is a mistake that is both easy to make and easily bypassed all testing for a year, up to Chrome v56.

We're running a multiplatform Win/Linux/etc environment and use Microsoft CAs for convenience. The mistake derives from when the CA gets imported in the Microsoft CA. The signature algorithm is chosen only once, and it's easy for a sysadmin to overlook this if one is not fully aware of the upcoming TLS 1.3 spec's requirements of curve/hash matching.

In our environment everything tested OK with all browsers up to last Friday. On Monday, Chrome v56 started rolling out, and a number of the IIS Servers became unavailable due to the ERR_CONNECTION_RESET problem.

Note that Apache2 servers using these certificates are still perfectly fine.

The problem needs three things to trigger:

  1) An IIS web server that follows the logic described in https://groups.google.com/a/tagpma.org/forum/#!topic/tagpma-general/_NbjhvKJ4qI/discussion

  2) Web server certificates using a mismatched signature algorithm

  3) A web client that follows the TLS 1.3 spec and stops advertising the (mismatched) extra sig algos (IE and Firefox are still fine)


After this, the only workarounds we've found so far are to 

  a) start using IE for the broken TLS connections and
  b) reimport the CA and reroll new certificates for the servers

While we're not asking you to support a broken config, it would have been good to warn about the problem beforehand. Now we went from all green to connection refused over the weekend.

As this specific config still tests okay with Chrome and Apache2, and other web servers, it might be a good idea to add a warning notification in the F12 Dev mode's Security overview.

As a side note - this change has seemingly exposed an apparent issue/bug between NGINX/OpenSSL, ECDSA certs, and VirtualHosting Certificates with SNI.

If you configure a stock ubuntu 14.04 system w/NGINX, and set 2+ ECDSA certs to be returned on the same port via SNI, for some unknown reason - NGINX returns SHA256 as the hash in the Server Key Exchange for one (first?) certificate, but the rest for some reason get SHA1 as the hash in the Server Key Exchange. 

Verified that all Certs were ECDSA/SHA256, and appropriate ciphers were being negotiated  (TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) in Server Hello).

Prior to this change, this issue went unnoticed because SHA1 was accepted fine with Chrome.

Posting this here to help if anyone else runs into the same issue. Chrome does not give great error reporting on this, shows cert is valid but site is not secure ( SSL_PROTOCOL_ERROR (net_error -107)).

That sounds like this bug, which is supposed to be fixed in the latest 14.04 OpenSSL package. Is it not?
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1550643

jmedley: This happened in M56. Why remove the label?

Another side note - this change exposed an issue with default settings on F5 load balancers: https://support.f5.com/csp/article/K14783

Because SSL Sign Hash is set to ANY, SHA1 is always selected, resulting in the ERR_SSL_PROTOCOL_ERROR. It appears to be unable to "automatically select a more suitable hash". The question now is, should I force it to SHA256 or SHA384 and what is the client support? If the only supported curve is P-256, is it safe to assume that SHA384 is pointlessly wasteful?

Worth noting that many useful tools, such as SSL Labs, do not report the hash used in the Server Key Exchange, making this issue difficult to track down. I know that's not your problem, rather that it caught me off guard. OpenSSL s_client was the most helpful: openssl s_client -connect fqdn.com:443 < /dev/null 2> /dev/null | grep "Peer signing digest"

The Chromium blog post announcing this change was a little less than clear on what was actually affected. We originally read it as "SHA-512 relies on SHA-1 and both are being removed as 'hash' options in cipher selection.", where I now realize it means "For hashes used in Server Key Exchange messages, SHA-512 is wasteful because Chromium doesn't support curves larger than 384 bits and SHA-1 is just downright bad. We're removing support for both when used with ECDSA."

My apologies for being a bit of a killjoy (thankfully I caught this issue just before it affected our production systems). Truly, I thank you for making the world a safer place!

Yeah, if you only support P-256, SHA-256 is the ideal hash. I would be surprised if there existed TLS 1.2 clients which only accepted SHA-1 with P-256. (Though I don't know for sure.)

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). It's supposed to be fixed in the latest version.

This launched a while ago.