Recent regression in SSL session reuse

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Recent regression in SSL session reuse

Jeremy Evans-5
After an OpenBSD upgrade, one of Ruby's tests for SSL session
reuse started to fail.  After some debugging, I have found that
if a maximum SSL version is not set by a client, then session
reuse does not work.  Setting a minimum version does not have
an effect.

At the bottom of this email is an example Ruby program showing
the issue.  If you save it to t.rb, you can then run:

  pkg_add ruby%2.6
  ruby26 t.rb

It will print out three lines, showing whether session reuse is
enabled:

1) When not setting max or min version
2) When setting max version
3) When setting min version

The behavior has changed recently, so I believe this to be a
regression.  Older versions would allow reuse of sessions when the
max SSL version was not set, but newer versions only allow reuse of
sessions if setting the max SSL version.

  OpenBSD 6.7-current (GENERIC.MP) #272: Mon Jun 15 01:54:58 MDT 2020
  [nil, true]
  ["max", true]
  ["min", true]

  OpenBSD 6.7-current (GENERIC) #325: Wed Jul  8 10:25:43 MDT 2020
  OpenBSD 6.7-current (GENERIC.MP) #376: Mon Jul 27 11:51:27 MDT 2020
  [nil, false]
  ["max", true]
  ["min", false]

So it looks like this behavior changed between June 15 and July 8.

If the Ruby program below is not sufficient to diagnose this issue,
please let me know and I'll see if I can translate it to C.  I checked
and the min_version call is calling SSL_CTX_set_min_proto_version(3),
and that is the only change it makes.

Thanks,
Jeremy


# t.rb file:

require 'net/http'

[nil, 'max', 'min'].each do |meth|
  http = Net::HTTP.new("google.com", 443)
  http.use_ssl = true
  if meth
    http.send("#{meth}_version=", :TLS1)
  end

  http.start
  http.get("/")
  http.finish

  http.start
  http.get("/")

  socket = http.instance_variable_get(:@socket).io
  p [meth, socket.session_reused?]
end

Reply | Threaded
Open this post in threaded view
|

Re: Recent regression in SSL session reuse

Theo Buehler-3
On Wed, Jul 29, 2020 at 02:57:33PM -0700, Jeremy Evans wrote:
> After an OpenBSD upgrade, one of Ruby's tests for SSL session
> reuse started to fail.  After some debugging, I have found that
> if a maximum SSL version is not set by a client, then session
> reuse does not work.  Setting a minimum version does not have
> an effect.

This is an expected side-effect of switching TLS_method() to default to
TLSv1.3

https://github.com/openbsd/src/commit/94149d15d762bdbf7eef74c417c53d2b8dc7dd12

By setting the max version to TLSv1 with :TLS1 (or any of the other
defined versions :TLS1_1 or :TLS1_2), you use the legacy stack which
supports session resumption. The minimum version is already TLSv1, so
setting the minimum version to :TLSv1 has no effect.

In TLSv1.3, the session resumption feature has been merged with
pre-shared keys, which we may eventually support, but that's not going
to happen very soon:

https://tools.ietf.org/html/rfc8446#page-15

Reply | Threaded
Open this post in threaded view
|

Re: Recent regression in SSL session reuse

Jeremy Evans-5
On 07/30 08:06, Theo Buehler wrote:

> On Wed, Jul 29, 2020 at 02:57:33PM -0700, Jeremy Evans wrote:
> > After an OpenBSD upgrade, one of Ruby's tests for SSL session
> > reuse started to fail.  After some debugging, I have found that
> > if a maximum SSL version is not set by a client, then session
> > reuse does not work.  Setting a minimum version does not have
> > an effect.
>
> This is an expected side-effect of switching TLS_method() to default to
> TLSv1.3
>
> https://github.com/openbsd/src/commit/94149d15d762bdbf7eef74c417c53d2b8dc7dd12
>
> By setting the max version to TLSv1 with :TLS1 (or any of the other
> defined versions :TLS1_1 or :TLS1_2), you use the legacy stack which
> supports session resumption. The minimum version is already TLSv1, so
> setting the minimum version to :TLSv1 has no effect.
>
> In TLSv1.3, the session resumption feature has been merged with
> pre-shared keys, which we may eventually support, but that's not going
> to happen very soon:
>
> https://tools.ietf.org/html/rfc8446#page-15

Theo,

Thank you very much for the information.  I'll try to get a change
committed upstream now that I know the behavior is expected.

Thanks,
Jeremy