Re: session resumption tls1.2/tls1.3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Mon, Jul 17, 2017 at 1:54 AM, Matt Caswell <matt@xxxxxxxxxxx> wrote:


On 14/07/17 20:18, Neetish Pathak wrote:
>
>
> On Fri, Jul 14, 2017 at 2:54 AM, Matt Caswell <matt@xxxxxxxxxxx
> <mailto:matt@xxxxxxxxxxx>> wrote:
>
>
>
>     On 13/07/17 23:52, Neetish Pathak wrote:
>     > Hi All,
>     > Help with these queries please,
>     >
>     > 1) Is it possible to use external session files (with session info as
>     > identifiers or tickets for out of band resumption) for session
>     > resumption in TLS 1.2. Does it need some kind of callback like the way
>     > it is used in TLS 1.3  with (SSL_set_psk_find_session_callback) /
>     > SSL_set_psk_use_session_callback
>
>     I'm not entirely clear what you're asking here. The callbacks you
>     mention are for setting up an external PSK in TLSv1.3. In TLSv1.3 we use
>     an SSL_SESSION object to encapsulate the PSK details. This is different
>     to session resumption, where the server sends the session details in a
>     NewSessionTicket message in one connection, so that we can "resume" it
>     in a later connection.
>
>     So if your question is really "can you external session files for PSK in
>     TLSv1.2" then the answer is no. PSK works completely differently in
>     TLSv1.2.
>
>
> Thanks Matt, Apologies for ambiguity in the question
>
> What I mean to ask is it possible to use out of band resumption in TLS 1.2?
> How I perform the resumption in my programs using TLS 1.2 is as follows :
> 1)  Connect client to the server  for the first time
> 2) when the server sends session id or tickets as the case may be,
> new_session_callback is invoked on the client side and I save the
> session in a pem file using PEM_write_bio_SSL_SESSION
> 3)Now when connecting client to the server next time, I read the session
> from the pem file and set using SSL_set_session.
> 4)Session resumption is initiated from the client side and the server
> works as expected since it had been caching the session and was not killed.
>
> I observe that the second connection (and subsequent connections) takes
> place using resumption. As per my understanding, this is called in-band
> resumption
>
> Now my question is if, I kill the server. I re-initialze the server and
> want to use the session(pem) file to connect to the server (this is a
> fresh connection which should take place using resumption).
> In that case, I will need to set the session on both the ends right? Is
> this approach correct? In that case, how should one implement it.
> This is out-of-band resumption for TLS 1.2 as per my understanding.
> Please correct me if I am wrong

The term out-of-band resumption is somewhat confusing. Anyway, the
server maintains a session cache. That cache can either be internal
(i.e. maintained by OpenSSL), or external (maintained by your own
application code). In the default case a server will just use the
internal session cache. You can populate that cache manually using
SSL_CTX_add_session(). So if you have a set of pre-existing SSL_SESSION
objects (perhaps loaded from a file) you can manually populate that
cache at application startup.



Hi ,
thanks Matt, this is helpful


One more query on how I can enable 0.5 RTT data from the server side. It is mentioned in TLS 1.3 specification. I thought it can be implemented by sending early data  from server side after reading the early data. But then how can that data be read on the client side since read_early_data api is invalid on client side ?

Thanks
Best Regards,
Neetish

Matt
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux