On 6/25/15, 5:17 AM, "Remi Gacogne" <[email protected]> wrote:
Hey Remy, thanks for your feedback! > >However, I have some concerns about the use of >SSL_set_session_secret_cb() for this feature, because it was clearly not >designed for this kind of manipulation. It has been removed from >BoringSSL [1] and simply enabling this callback in OpenSSL, regardless >of what is done in the callback itself, disables TLS session ticket >(rfc5077) [2], which I believe is an issue. >It also means that you have to use flags that are internals to OpenSSL, >and may change in the future. I was unaware that BoringSSL removed the callback, but in that case, could we limit this feature to only OpenSSL? I¹m also not seeing how using this callback prevents rfc5077, could you please elaborate. I wholeheartedly agree with you that using internal OpenSSL flags is not ideal, but the workaround would be to check every single cipher for the Signature Algorithm. I could change it to use these if that¹s preferred, but it will definitely bloat the code, plus is less maintainable. Change in the future is definitely something that is a flaw to this implementation. I¹m still trying to find a way around this one. >Lastly, switching the SSL_CTX based only on the suites sent by the >client in ClientHello means that you effectively bypass the suites >preference set on HAproxy, if any. If the first suite sent by the client >requires an ECDSA certificate, you will switch to a SSL_CTX supporting >only ECDSA suites, even if the server preferences prefer some suites >using RSA better than ECDSA ones. This is quite a change from the >HAproxy default, which is to take into account the server preferences >first [3]. I see that now. But in the current implementation, doesn¹t it always just use the default CTX if the client doesn¹t specify SNI? In that case, you¹d still be limited to the signature algorithm of the default CTX. It¹s possible to take the server preferences in mind. However, wouldn¹t that lead to a situation where the server wants to use Signature Algorithm A, but the client only supports B, and then the client can¹t connect? In my mind, choosing the signature algorithm based on what the client supports is a good idea as it guarantees that the client can use that algorithm. Then, the server can use w/e cipher suite it wants in terms of Key-Exchange and symmetric-encryption. Tying this feature into 1.0.2 would definitely make it easier, I agree. It just will hinder adoption. Thoughts? -Dave
