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

[David Woodhouse]

On Tue, 2016-07-26 at 23:52 +, 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 WoodhouseOpen 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

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

[David Benjamin]

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