On Tue, 2016-07-26 at 23:52 +0000, David Benjamin wrote: > Ah, you've hit upon a slew of odd behaviors which only got fully fixed on the > master branch.
Thanks for the comprehensive response. I'm not going to touch that with a barge-pole then. > (I'm not familiar with DTLS1_BAD_VER, but if it's a different > protocol version, it sounds like you should configure it like other > versions and not mess with session resumption bugs.) It's a different protocol version, and the *only* way it ever gets used in the modern world is with a session resume (because that's how Cisco's AnyConnect VPN works). Hence the thought process was that if the session resume would *force* the protocol version (which you now told me it shouldn't, for the client), then I wouldn't *need* any other method of specifying it. In RT#3711 we had previously talked about the option of enabling full support via something like DTLSv0_9_client_method(), and it had been decided not to — on the basis that the existing SSL_OP_CISCO_ANYCONNECT hack was sufficient. That's less true now with the generic DTLS_client_method() and DTLS_ANY_VERSION, because the SSL_OP_CISCO_ANYCONNECT hack needs to be propagated into a lot more places and it actually ends up being *cleaner* to implement it "properly" AFAICT. I've updated my submission in PR#1296 accordingly; thanks for the feedback. https://github.com/openssl/openssl/pull/1296 -- David Woodhouse Open Source Technology Centre david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
