4 ms·

Support for parallel ECDSA / RSA certificates

82 points by runesoerensen 10y ago

koolba 10y ago
Is this SNI?
- Fry-kun 10y ago
  That can't be it, SNI certs had been supported for a long time already
  - koolba 10y ago
    That's what I thought as well. The title and commit message doesn't say much else though. EDIT: Ah the other comment on this thread explains it. It's not multiple certs for different domains, it's multiple certs for different types of keys.
    - homero 10y ago
      Right https://blog.cloudflare.com/sha-1-deprecation-no-browser-left-behind/ https://blog.cloudflare.com/sha-1-deprecation-no-browser-lef...
- prdonahue 10y ago
  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: SHA512/RSA SHA512/ECDSA SHA384/RSA SHA384/ECDSA SHA256/RSA SHA256/ECDSA SHA224/RSA SHA224/ECDSA SHA1/RSA SHA1/ECDSA 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. [1] - https://www.ietf.org/rfc/rfc5246.txt https://www.ietf.org/rfc/rfc5246.txt [2] - https://www.cloudshark.org/captures/88b6405ca75d/decode?frame=5&window=yes https://www.cloudshark.org/captures/88b6405ca75d/decode?fram... [3] - https://blog.cloudflare.com/tls-certificate-optimization-technical-details/#step4certificatechainvalidation https://blog.cloudflare.com/tls-certificate-optimization-tec...
pbnjay 10y ago
The linked ticket has more detail than this: https://trac.nginx.org/nginx/ticket/814 https://trac.nginx.org/nginx/ticket/814 Basically, allows ECDSA certificates alongside RSA.
- dang 10y ago
  Ok, we changed the URL to that from https://trac.nginx.org/nginx/changeset/51e1f047d15d5602a8250dfe9192d0eae71e6fcc/nginx https://trac.nginx.org/nginx/changeset/51e1f047d15d5602a8250....
nisa 10y ago
Nice! Here Apache 2.4 was faster. Now that Let's Encrypt supports ECC certs for a while you can use both to reap the benefits.
prdonahue 10y ago
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. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=409901 https://bugs.chromium.org/p/chromium/issues/detail?id=409901 [2] https://blog.cloudflare.com/tls-certificate-optimization-technical-details/ https://blog.cloudflare.com/tls-certificate-optimization-tec...
- mtgx 10y ago
  Google stopped supporting Windows XP last month. http://arstechnica.com/gadgets/2016/04/chrome-50-ends-support-for-windows-xp-os-x-10-6-other-old-versions/ http://arstechnica.com/gadgets/2016/04/chrome-50-ends-suppor...
  - prdonahue 10y ago
    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.
    - derefr 10y ago
      Can't we just put up a bounty for a computer worm that wipes out all the XP machines in the world, and then stop having this conversation? :)
      - dottedmag 10y ago
therealmarv 10y ago
does somebody know how an example config of this will look like in nginx 1.11.0 ?

82 points by runesoerensen 10y ago

koolba 10y ago

Is this SNI?

Fry-kun 10y ago
That can't be it, SNI certs had been supported for a long time already
- koolba 10y ago
  That's what I thought as well. The title and commit message doesn't say much else though. EDIT: Ah the other comment on this thread explains it. It's not multiple certs for different domains, it's multiple certs for different types of keys.
  - homero 10y ago
    Right https://blog.cloudflare.com/sha-1-deprecation-no-browser-left-behind/ https://blog.cloudflare.com/sha-1-deprecation-no-browser-lef...
prdonahue 10y ago
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: SHA512/RSA SHA512/ECDSA SHA384/RSA SHA384/ECDSA SHA256/RSA SHA256/ECDSA SHA224/RSA SHA224/ECDSA SHA1/RSA SHA1/ECDSA 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. [1] - https://www.ietf.org/rfc/rfc5246.txt https://www.ietf.org/rfc/rfc5246.txt [2] - https://www.cloudshark.org/captures/88b6405ca75d/decode?frame=5&window=yes https://www.cloudshark.org/captures/88b6405ca75d/decode?fram... [3] - https://blog.cloudflare.com/tls-certificate-optimization-technical-details/#step4certificatechainvalidation https://blog.cloudflare.com/tls-certificate-optimization-tec...

pbnjay 10y ago

The linked ticket has more detail than this: https://trac.nginx.org/nginx/ticket/814 https://trac.nginx.org/nginx/ticket/814 Basically, allows ECDSA certificates alongside RSA.

dang 10y ago
Ok, we changed the URL to that from https://trac.nginx.org/nginx/changeset/51e1f047d15d5602a8250dfe9192d0eae71e6fcc/nginx https://trac.nginx.org/nginx/changeset/51e1f047d15d5602a8250....

nisa 10y ago

Nice! Here Apache 2.4 was faster. Now that Let's Encrypt supports ECC certs for a while you can use both to reap the benefits.

prdonahue 10y ago

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. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=409901 https://bugs.chromium.org/p/chromium/issues/detail?id=409901 [2] https://blog.cloudflare.com/tls-certificate-optimization-technical-details/ https://blog.cloudflare.com/tls-certificate-optimization-tec...

mtgx 10y ago
Google stopped supporting Windows XP last month. http://arstechnica.com/gadgets/2016/04/chrome-50-ends-support-for-windows-xp-os-x-10-6-other-old-versions/ http://arstechnica.com/gadgets/2016/04/chrome-50-ends-suppor...
- prdonahue 10y ago
  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.
  - derefr 10y ago
    Can't we just put up a bounty for a computer worm that wipes out all the XP machines in the world, and then stop having this conversation? :)
    - dottedmag 10y ago

therealmarv 10y ago

does somebody know how an example config of this will look like in nginx 1.11.0 ?