Query related to session resumption in TLS1.3

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

Query related to session resumption in TLS1.3

OpenSSL - User mailing list
Hi All,

I am in process of using TLS1.3 using openssl 1.1.1b version in my client application. In order to use session resumption, I have implemented an external cache when acting as the client. The key to the cache is combination of host and port and the value  associated is SSL_SESSION*.   Before calling ssl_connect, I am checking if the entry corresponding to the key exists in the map. If it exists, I am calling SSL_set_session. After ssl_connect, I am checking if the session is reused or not using SSL_Session_Reused. If its not reused, I am inserting the new session obtained as a result of call to SSL_get1_session() in the map.

Pseudo code is as follows:

std::map<std::string, SSL_SESSION*> sessionCache;
/* Generate an SSL client context. */
SSL_CTX* ctx = SSL_CTX_new(TLS_method());
SSL* ssl = SSL_new(ctx);
 
//Check if we have a stored session 
it = sessionCache.find (key);
if (it != sessionCache.end()) 
{
SSL_set_session (ssl, it->second)
}

SSL_connect(ssl);
int reUsed = SSL_session_reused(ssl);
if (!reUsed) {
session = SSL_get1_session(ssl);
sessionCache.insert (key, session);
}

The above flow works well using TLS1.2. I can see that SSL_session_reused returns true in the second connection. 

But the same flow does not work for TLS1.3. In TLSv1.3, sessions are established after the main handshake has completed. So, I have implemented the callback  SSL_CTX_sess_set_new_cb.  And in the callback, I am storing the session into the cache. In subsequent connections, the session is present in the map, SSL_set_session API returns true. But SSL_session_reused is always returning false.

I have the following queries:
1. Is the above mentioned approach applicable for TLS 1.3? 
2. There is a mention that PreShared keys are used for session resumption in TLS1.3.  Can someone please clarify, how should I make my client send psk using openssl for subsequent connection?

Reply | Threaded
Open this post in threaded view
|

Re: Query related to session resumption in TLS1.3

Viktor Dukhovni
On Thu, May 16, 2019 at 04:22:13PM +0000, shalu dhamija via openssl-users wrote:

> But the same flow does not work for TLS1.3. In TLSv1.3, sessions are
> established after the main handshake has completed. So, I have implemented
> the callback SSL_CTX_sess_set_new_cb. And in the callback, I am storing
> the session into the cache. In subsequent connections, the session is
> present in the map, SSL_set_session API returns true. But SSL_session_reused
> is always returning false.

This is not expected, perhaps your code is not quite right.

> I have the following queries:
> 1. Is the above mentioned approach applicable for TLS 1.3?

Yes.  It works, for example, in Postfix:

   https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L543-L547
   https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L1001-L1004
   https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L1146

> 2. There is a mention that PreShared keys are used for session
> resumption in TLS1.3.

This is misleading.  In TLS 1.3, the PSKs and session tickets have
been internally unified into a single protocol mechanism.  This
internal detail is not something that users need to worry about.

> Can someone please clarify, how should I make my
> client send psk using openssl for subsequent connection?

This is not the right question.  SSL_set_session() is all you need
for session resumption.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Query related to session resumption in TLS1.3

shalu dhamija
Hi Viktor,
Thanks for your response. In my code, somehow, the ssl_read was not getting called ( due to some bug) due to which the session ticket was not being read resulting in no callback. I have fixed it and its working now.
Now the resumption using TLS1.3 is working fine but I want to clarify the following behavior:
As per openssl documentation:
'The default number of tickets is 2; the default number of tickets sent following a resumption handshake is 1'. (https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_num_tickets.html)
But in my case, following the resumption handshake, I am always getting two session tickets from the server. Is this behavior fine as it is server dependent.

Regards,
Shalini Dhamija
'
 

On Thursday, 16 May, 2019, 10:10:57 pm IST, Viktor Dukhovni <[hidden email]> wrote:


On Thu, May 16, 2019 at 04:22:13PM +0000, shalu dhamija via openssl-users wrote:

> But the same flow does not work for TLS1.3. In TLSv1.3, sessions are
> established after the main handshake has completed. So, I have implemented
> the callback SSL_CTX_sess_set_new_cb. And in the callback, I am storing
> the session into the cache. In subsequent connections, the session is
> present in the map, SSL_set_session API returns true. But SSL_session_reused
> is always returning false.

This is not expected, perhaps your code is not quite right.

> I have the following queries:
> 1. Is the above mentioned approach applicable for TLS 1.3?

Yes.  It works, for example, in Postfix:

  https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L543-L547
  https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L1001-L1004
  https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L1146

> 2. There is a mention that PreShared keys are used for session
> resumption in TLS1.3.

This is misleading.  In TLS 1.3, the PSKs and session tickets have
been internally unified into a single protocol mechanism.  This
internal detail is not something that users need to worry about.

> Can someone please clarify, how should I make my
> client send psk using openssl for subsequent connection?

This is not the right question.  SSL_set_session() is all you need

for session resumption.


--
    Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Query related to session resumption in TLS1.3

Viktor Dukhovni
On Sun, Jun 09, 2019 at 10:39:36AM +0000, shalu dhamija wrote:

>   "The default number of tickets is 2; the default number of tickets sent
>   following a resumption handshake is 1".  But in my case, following the
>   resumption handshake, I am always getting two session tickets from the
>   server.  Is this behavior fine as it is server dependent.

The behaviour is server-impementation dependent.  If the server is
not using OpenSSL, it might always return multiple tickets.  This
is IMHO unwise, because each resumption increases the number of
available tickets without bound.

In conversation with Matt Caswell he and I came up with the current
OpenSSL design in which a client that uses a pool of N concurrent
sessions *without* ticket re-use (each session repeatedly obtaining
a "continuation" ticket) obtains the requisite tickets after N-1
full handshakes, at which point no excess tickets are delivered so
long as the client's concurrency needs are met.

Servers also have the (non-default) *option* of resuming sessions
with a valid ticket *without* returning a new ticket.  Postfix makes
use of this option to vend exactly one ticket per full handshake,
and not return any new tickets on resumption.  Client MTAs that
support resumption are expected to re-use tickets.

--
        Viktor.