Ah, you've hit upon a slew of odd behaviors which only got fully fixed on the master branch.
On Tue, Jul 26, 2016 at 7:30 PM David Woodhouse <dw...@infradead.org> wrote: > The deprecation of the version-specific methods such as > DTLSv1_client_method() has introduced a regression — the > SSL_OP_CISCO_ANYCONNECT hack doesn't work with DTLS_client_method(). > > I'm looking into fixing that (in PR#1296 along with a test case and > some fixes for various other regressions). In doing so, I uncovered a > slightly more generic question... > > If I am resuming a session with SSL_set_session(), and that previous > session used a specific protocol... should we negotiate that *same* > protocol again, effectively setting the minimum and maximum protocol > versions to s->session->ssl_version? > As a server, yes. Mismatching resumed and negotiated version isn't interoperable with any client out there. This was fixed in 1.0.2 I believe with: https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=9e189b9dc10786c755919e6792e923c584c918a1 A server must first do version negotiation and then, if the version does not match the offered session, decline to resume a session and negotiate a full handshake. As a client, no. This was the old behavior and causes all kinds of problems. It should not be restored. See the discussions here: https://github.com/openssl/openssl/pull/603 https://github.com/tlswg/tls13-spec/issues/136 If configured to offer, say, a TLS 1.1 session while the maximum version is TLS 1.2, offer the session BUT advertise a maximum version of TLS 1.2. If the server accepts the session, treat it as a fatal error if the session's version does not match the negotiated version. Anything else will cause tons of interoperability problems or weird behaviors. (Although 1.0 through 1.2 are more-or-less the same protocol, assuming that "sessions" are somehow analogous across protocol versions is a bad idea. Say you tried a resume a 1.2 AES-GCM session at 1.1. Also 1.3 resumption is completely different from 1.2 resumption and definitely should not be mixed.) > Given that DTLS1_BAD_VER only *ever* needs to be used in a session > resume, that would be a perfectly acceptable way to obtain it... > (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.) David
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
