On Wed, Jun 24, 2015 at 03:06:32PM +0000, Dave Zhu (yanbzhu) wrote: > Hey Willy, > > Lukas explained it pretty well, but I can expound on it some more. > > You can imagine a situation where HAProxy has 2 certificates of different > key types; one ECDSA and one RSA. In the current codebase, if no SNI is > used, the certificate that is used will be whichever certificate is the > default (i.e. the one that is first specified in the config). So we would > have 2 possible paths: > > 1. ECDSA was specified first. This has the effect of only supporting > cipher suites that has ECDSA. If the client does not support ECDSA, then > it would mean that the connection will fail, even though the server has an > RSA certificate. > 2. RSA was specified first. This means that ECDSA cipher suites would > never be used, which can decrease performance for initial handshakes as > well as have a negative security impact. > > What I propose would address both of these issues. If the client prefers > RSA or only supports RSA, then the RSA certificate is presented. However, > if the client supports ECDSA, then we would use the ECDSA certificate.
Yes I understand that thanks to Lukas' explanation. Indeed this is quite interesting. What I'm understanding here is that instead of using SNI only as the key to pick a cert, we want the (SNI, algo) combination. Coudln't we have two certs per SNI entry ? One in RSA form, the other one in ECDSA, and only provide what is supported ? We could even consider that whenever a client advertises support for ECDSA we should provide it first as it saves CPU cycles. I guess that RSA won't go away for a long time and might still be there in 10 years anyway, so selecting first on SNI and second on the algo with a fallback to the only cert present in the SNI for most cases where there's a single one sounds the right approach. > Lukas, > I believe the reason that apache calls out 1.0.2 is this line in the > OpenSSL (1.0.1l to 1.0.2a) changelog: > > * Add support for certificate stores in CERT structure. This makes it > possible to have different stores per SSL structure or one store in the > parent SSL_CTX. Include distint stores for certificate chain verification > and chain building. New ctrl SSL_CTRL_BUILD_CERT_CHAIN to build and store > a certificate chain in CERT structure: returing(sic) an error if the chain > cannot be built: this will allow applications to test if a chain is > correctly configured. > > In openssl <= 1.0.1, we can load multiple certs/keys into a single > SSL_CTX. However, they must all have the same cert-chain. I believe that > this 1.0.2 feature addresses this issue via certificate stores, and so can > then use the existing s3server cipher suite selection code to select the > correct certificate/key inside the library. This would alleviate the need > to hook into a callback, which is what I¹m doing here. I could be wrong but I think that we have as many SSL_CTX as we load certs, and we pick the correct one based on the SNI, so it should probably not be an issue in our case with either version. > The diff I submitted is coded to OpenSSL 1.0.1, and will still work in > 1.0.2. The 1.0.2 change will make it easier to support this feature in > combination with SNI. We do handle SNI by ourselves right now. We have a callback from which we look up the hostname in the cert tree and pick the best match (either the perfect match or a matching wildcard). We can apply the logic we want there. > We¹ll have to discuss which approach we want to take > going forward; 1.0.2 is still relatively young, and so requiring adopters > to have that version may cause additional friction. Absolutely, especially if we find that it doesn't bring any benefit over what we currently have due to a different architecture. BTW, please take care of surrounding your code with the appropriate ifdefs if you think you're using features from recent libs. Older ones are still supported (and used). 0.9.8 is still supported by openssl, and older ones are still deployed at some places or in older LTS distros or systems which do ship their own patched versions. For example, RHEL4 ships 0.9.7, along with a 0.9.6 compatibility package to port old programs from RHEL2.1! I must confess I stopped testing the 0.9.6 builds 2 years ago when my last machine having it was replaced :-) If you really don't know and mess a bit, that's not dramatic, because the possible build issues will sooner or later be reported. But it's better to be careful with this in mind before breaking things too much. cheers, Willy
