[openssl-dev] Session resume with different TLS version?

[David Woodhouse]

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?

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...

[David Benjamin]

Ah, you've hit upon a slew of odd behaviors which only got fully fixed on
the master branch.

Post by David Woodhouse
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.)

Post by David Woodhouse
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

[David Woodhouse]

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