<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Hi!</div><div><br></div><div>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</div><div>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   <br></div><div>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.</div></div><div dir="ltr"><br></div><div dir="ltr"><div>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. <br></div></div><div dir="ltr"><br></div><div dir="ltr">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).<div><div><br></div></div><div>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.<br></div><div><br></div><div>Regards Ingela - Erlang  OTP/Team - Ericsson AB<br></div><br><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den tors 2 apr. 2020 kl 11:41 skrev Roger Lipscombe <<a href="mailto:roger@differentpla.net">roger@differentpla.net</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Further investigation:<br>
<br>
If I purge the server's session cache, the client *never* reuses a<br>
session from that point onward. The same happens if I add suitable<br>
retry logic to the client and then restart the server node.<br>
<br>
It looks like it grabs the previous session from the client session<br>
cache, even though it knows that it's no longer valid. The server<br>
knows nothing of this session ID, so it returns a new session.<br>
OTP-22.2.8, incidentally.<br>
<br>
On Thu, 2 Apr 2020 at 10:18, Roger Lipscombe <<a href="mailto:roger@differentpla.net" target="_blank">roger@differentpla.net</a>> wrote:<br>
><br>
> On Thu, 2 Apr 2020 at 10:07, Roger Lipscombe <<a href="mailto:roger@differentpla.net" target="_blank">roger@differentpla.net</a>> wrote:<br>
> > I'm investigating SSL session reuse, and I can't get my client to<br>
> > actually reuse sessions. I'm using the escript below.<br>
><br>
> I looked in the OTP source code; it only reuses client sessions if<br>
> verify is set to verify_peer.<br>
><br>
> Obviously, that causes problems in the "localhost" case, so I stubbed<br>
> that out with {verify_fun, {fun yolo/3, undefined}}.<br>
><br>
> At that point, it started reusing session IDs, but the<br>
> 'session_resumption' value still came back negative. What's that<br>
> about? I was hoping to use that to assert that the session *had* been<br>
> reused.<br>
</blockquote></div></div></div></div></div>