SSL client reuse_sessions not working?

[Ingela Andin]

Hi!

To answer your questions. Reusing a TLS session (pre TLS-1.3)  means that
the client has to have made at least one successful handshake against the
server
and that both the client and the server has saved session parameters from
that handshake that enables them to do a so called abbreviated handshake.
The abbreviated handshake
skips most of the negotiation including certificate validation. So in order
to make it a good idea form a security point of view, to reuse a session,
you need to verify the full handshake.

The server is the one that decides if a session may be reused, the client
is the one that initiates the possible reuse. There is a save option that
will make a specific connections session data to be saved in the database,
and when that connection returns, the session will be reusable. You can
then ask the connection for its session id and provide it to the next
connect.

If you spawn a lot of parallel request, there might be quite a few that
does not find a session to reuse, also this behavior in a client could
cause a lot of equivalent sessions taking up room in the session database.
That is why be default the client no longer saves equivalent sessions.  If
you empty the server session table it will not agree to reuse the saved
client session, and you will not get any new until the saved session
expires (unless the save option is used). The default expiration time is
quite long (the "recommended" by the RFC).

Regardless of our implementation, this mechanism is memory consuming and
has security problems. There is another mechanism called session tickets
that is an extension to TLS that was never implemented by us and that also
has its own security problems. TLS-1.3 has a mechanics inspired by session
tickets but better integrated into the protocol and that we have
implemented.

Regards Ingela - Erlang  OTP/Team - Ericsson AB


Den tors 2 apr. 2020 kl 11:41 skrev Roger Lipscombe <roger@REDACTED
>:

> Further investigation:
>
> If I purge the server's session cache, the client *never* reuses a
> session from that point onward. The same happens if I add suitable
> retry logic to the client and then restart the server node.
>
> It looks like it grabs the previous session from the client session
> cache, even though it knows that it's no longer valid. The server
> knows nothing of this session ID, so it returns a new session.
> OTP-22.2.8, incidentally.
>
> On Thu, 2 Apr 2020 at 10:18, Roger Lipscombe <roger@REDACTED>
> wrote:
> >
> > On Thu, 2 Apr 2020 at 10:07, Roger Lipscombe <roger@REDACTED>
> wrote:
> > > I'm investigating SSL session reuse, and I can't get my client to
> > > actually reuse sessions. I'm using the escript below.
> >
> > I looked in the OTP source code; it only reuses client sessions if
> > verify is set to verify_peer.
> >
> > Obviously, that causes problems in the "localhost" case, so I stubbed
> > that out with {verify_fun, {fun yolo/3, undefined}}.
> >
> > At that point, it started reusing session IDs, but the
> > 'session_resumption' value still came back negative. What's that
> > about? I was hoping to use that to assert that the session *had* been
> > reused.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20200403/ebc4a393/attachment.htm>