|
On 9/11/2018 9:46 AM, Viktor Dukhovni
wrote:
Part of the confusion is also using a version inflexible method on the client, that's rarely done. My test engineers like trying all the variations, including the ones nobody will ever use :-) Instead of "s_client -tls1" it is wiser to test with "s_client -no_ssl2 -no_ssl3 -no_tls1_1 -no_tls1_2". That is subtract the versions you don't want. IIRC that still leaves you "version flexible" even if only with a single version. In the application that's causing me trouble now, we start with SSLv23_method and then add SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3, and in this particular test case SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2. But how we construct the client configuration won't matter. The client says "the highest I support is 1.0" and the server says (to itself) "the lowest I support is 1.1; I don't even know how to say 'no' so I'm just giving up". The key piece that I was missing - I hadn't looked at and thought about the protocol enough - was that there's no version-independent way for the server to fail. If the server supports only versions larger than the client supports, it has no way to say "no". If the positions are reversed, the server counter-offers a version that the client then rejects as too old. Thanks again. -- Jordan Brown, Oracle Solaris |
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
