Curious to see how they handle Chrome on Windows XP advertising sigalg support for SHA-2/ECDSA but not being able to actually validate the certificate. We provided details[1] on the bug to Google and they agreed the behavior was incorrect, but Adam Langley felt that it wasn't worth making the change in BoringSSL:
> The code change in BoringSSL doesn't appear to be worth it. I think removing the cipher suites means that our ClientHello here is not unreasonable and, in the future, it sounds like we'll solve the problem by default by dropping XP support.
So long as nginx is examining the cipher suites in the ClientHello (as well as the TLS 1.2 signature_algorithms extension) to determine if the user agent can support ECDSA, they should be in good shape. That's the subsequent check[2] we ended up implementing.
Right, but that doesn't immediately remove the millions of XP machines still in use. My question was how nginx handles those inbound connections that falsely claim they can validate SHA-2/ECDSA signatures.
X.org bugzilla quip: "with a non-multisync monitor, it would destroy.. the.. monitor.. so- Our job here is to make sure that there are no such monitors left in the world. --Keith Packard, LCA2007"
Looks like that bug was reported for Chrome 37, which is the last version of Chrome to rely on the underlying OS for validating SHA-2 Certificates.
Chrome 38+ should be able to validate the cert.
"Chrome is capable of supporting SHA-2 certificates as of version 1.0, however through version 37 it is dependent on the operating system. For instance, on Windows Server 2003 without MS13-095 or Windows XP SP2 Chrome will not connect to pages using SHA-2 certs. Applying MS13-095 to Server 2003, or SP3 to Windows XP will allow Chrome to support SHA-2 on these legacy systems.
Chrome 38+ can validate SHA-2 certificates independently, even on systems like Server 2003 without MS13-095 applied."
No, it's not SNI (part of the original TLS extensions) but it's another TLS extension that was added[1] in TLS 1.2. Essentially the user agent advertises a list of the signature algorithms that they support for purposes of validating the signatures on the certificate (chain). It does so in pairs, as you'll see below.
For example, if you expand the last row in this CloudShark capture[2] all the way down to the signature_algorithms extensions (expand "Secure Sockets Layer" then "SSL Record Layer: Handshake Protocol: Client Hello" then "Handshake Protocol: Client Hello" and finally "Extension: Signature Algorithms") you'll see the following 10 pairs:
Your browser is telling the web server in the ClientHello that it can verify signatures that were created using the specified combination of hashing algorithms (e.g., SHA-256 or SHA-1) and signature algorithms (RSA or ECDSA). To save myself some typing here's how I've previously explained[3] the process:
> Then, for each certificate in the assembled chain, the browser extracts the signature provided by the issuing certificate authority (CA) and verifies it using the issuer’s public key. To do so, the browser uses the specified hashing algorithm — typically SHA-1 or SHA-256 — to create a digest of the data contained within the To Be Signed (TBS) Certificate section of the X509 structure (e.g., expiration date, valid hostnames, etc.).
> It then takes that digest, along with the issuer's public key and signature, and runs it through the "verify" function for the signature algorithm. If the output of this verify function is "true", the browser knows the structure is intact and unchanged from when the CA vetted it, as only someone in possession of the corresponding private key could have produced a valid signature.
Basically, allows ECDSA certificates alongside RSA.