session resumption tls1.2/tls1.3

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

session resumption tls1.2/tls1.3

neetish
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


2) In TLS 1.3, is early data not enabled for out of band PSK session resumption. Is it only possible with in-band session resumption. 
SSL_write_early_data always fails when I load a session from a session file to perform external PSK resumption before sending the session data. For in-band resumption it succeeds.

Thanks
Best Regards,
Neetish

 

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: session resumption tls1.2/tls1.3

Matt Caswell-2


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.


> 2) In TLS 1.3, is early data not enabled for out of band PSK session
> resumption. Is it only possible with in-band session resumption.
> SSL_write_early_data always fails when I load a session from a session
> file to perform external PSK resumption before sending the session data.
> For in-band resumption it succeeds.

Currently we only support early-data for ticket based resumption. You
cannot do it with an external PSK. However this PR (which is currently
going through review) will add that capability:

https://github.com/openssl/openssl/pull/3926

Matt

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: session resumption tls1.2/tls1.3

neetish


On Fri, Jul 14, 2017 at 2:54 AM, Matt Caswell <[hidden email]> 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

Thanks
Best Regards,
Neetish


Thanks


> 2) In TLS 1.3, is early data not enabled for out of band PSK session
> resumption. Is it only possible with in-band session resumption.
> SSL_write_early_data always fails when I load a session from a session
> file to perform external PSK resumption before sending the session data.
> For in-band resumption it succeeds.

Currently we only support early-data for ticket based resumption. You
cannot do it with an external PSK. However this PR (which is currently
going through review) will add that capability:

https://github.com/openssl/openssl/pull/3926

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: session resumption tls1.2/tls1.3

Matt Caswell-2


On 14/07/17 20:18, Neetish Pathak wrote:

>
>
> On Fri, Jul 14, 2017 at 2:54 AM, Matt Caswell <[hidden email]
> <mailto:[hidden email]>> 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.

Matt
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: session resumption tls1.2/tls1.3

neetish


On Mon, Jul 17, 2017 at 1:54 AM, Matt Caswell <[hidden email]> wrote:


On 14/07/17 20:18, Neetish Pathak wrote:
>
>
> On Fri, Jul 14, 2017 at 2:54 AM, Matt Caswell <[hidden email]
> <mailto:[hidden email]>> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: session resumption tls1.2/tls1.3

Viktor Dukhovni
In reply to this post by Matt Caswell-2
On Mon, Jul 17, 2017 at 09:54:39AM +0100, Matt Caswell wrote:

>                    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.

When server side (non-ticket) caches are enabled in Postfix it uses
a file-based key-value store.  The lookup key is the session id
sent by the client, and the value is the serialized session object.

So it is also possible to load saved sessions on demand.  In Postfix
this is used to share sessions within a pool of cooperating processes,
and the cache is deleted on restart, but that's a design choice
that other applications could (with care) make differently.  I
would avoid using session objects across changes in the OpenSSL
library version between the process that saved the session and the
process that's reading it.

--
        Viktor.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: session resumption tls1.2/tls1.3

Matt Caswell-2
In reply to this post by neetish


On 18/07/17 22:27, Neetish Pathak wrote:
> 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.

That is correct, and is as documented on this page:

https://www.openssl.org/docs/manmaster/man3/SSL_write_early_data.html

> But then how can that data be read on the client side since
> read_early_data api is invalid on client side ?

0.5 RTT data is sent from the server to an unauthenticated client. At
this point in the process the server has sent all of its messages
(including its Certificate/CertificateVerify/Finished messages) but it
has not received the Client Finished or any client
Certificate/CertificateVerify if one is going to be sent.

From the client's perspective 0.5 RTT data is received *after* it has
processed the server's Certificate/CertificateVerify/Finished messages),
and after it has sent its own Finished (and
Certificate/CertificateVerify if appropriate). In other words from the
client's perspective the server is fully authenticated and 0.5 RTT data
is indistinguishable from post-handshake data. Just use SSL_read() as
normal to receive it.

Matt
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: session resumption tls1.2/tls1.3

neetish
Thanks everyone for clarification on previous queries

1) I had a general query regarding the handshake resumptions. 
Since during the session resumption handshake in either TLS 1.2 or TLS 1.3 the key exchange does not take place, the client side and the server side both resume based on a previously set up session, so the master key is not going to change . Isn't the data sent post resumption handshake vulnerable to replay attacks ? why do we say that the data is vulnerable to replay only with enable-early data in tls 1.3. I think I am confused on some basics here. 

I am saying this because if I save the session in a file, the master key gets fixed. I see that during the resumption handshake too, the client hello message has a client_random value which as per my understanding is required for generating the master secret. But the master key is always read from the previous session info saved in the file, hence I am a little confused will the master secret change after every resumption connection.

2) If master secret doesn't change for the resumed connection, shouldn't it change on each handshake finish (full or resumption handshake) for more secure communication? 
I think that happens only on full-handshake in ephemeral type ciphers (e.g. ECDHE) but not in RSA type. Am I correct ?



Thanks
BR,
Neetish



On Wed, Jul 19, 2017 at 2:27 AM, Matt Caswell <[hidden email]> wrote:


On 18/07/17 22:27, Neetish Pathak wrote:
> 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.

That is correct, and is as documented on this page:

https://www.openssl.org/docs/manmaster/man3/SSL_write_early_data.html

> But then how can that data be read on the client side since
> read_early_data api is invalid on client side ?

0.5 RTT data is sent from the server to an unauthenticated client. At
this point in the process the server has sent all of its messages
(including its Certificate/CertificateVerify/Finished messages) but it
has not received the Client Finished or any client
Certificate/CertificateVerify if one is going to be sent.

From the client's perspective 0.5 RTT data is received *after* it has
processed the server's Certificate/CertificateVerify/Finished messages),
and after it has sent its own Finished (and
Certificate/CertificateVerify if appropriate). In other words from the
client's perspective the server is fully authenticated and 0.5 RTT data
is indistinguishable from post-handshake data. Just use SSL_read() as
normal to receive it.

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: session resumption tls1.2/tls1.3

neetish
In reply to this post by Matt Caswell-2


On Wed, Jul 19, 2017 at 2:27 AM, Matt Caswell <[hidden email]> wrote:


On 18/07/17 22:27, Neetish Pathak wrote:
> 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.

That is correct, and is as documented on this page:

https://www.openssl.org/docs/manmaster/man3/SSL_write_early_data.html


Thanks Matt
To send 0.5 RTT data I m sending the early_data from the server side just after the early_read data. But when I see the wire-shark logs, I see that the server data is sent only once the complete handshake has taken place. (which is the same as using SSL_write after SSL_accept).
I am performing following steps on client and server respectively as per understanding developed from previous discussions

Pseudocode for client

tcp_connect

write_early(data)

ssl_connect

if(early_data_write_failed){
      ssl_write(data)
}

ssl_read


Pseudocode for server

tcp_accept

read_early{

     if(read_early_success){
          write_early(data)
      }
}

ssl_accept

if(read_early_fail){
    ssl_read
    ssl_write(data)
}


I am measuring latency on the client side from TCP connection start  till it completes the read (ssl_read returns) (analogues to making a request from client and reading response).
Please suggest what may be going wrong basically with these queries

1) Why is there no difference (or negligible) in latencies when i use early write and then later ssl_read compared to when I execute normal write/read on the client side

2) Why does the server not send data (for early write) after the server Hello(and other encrypted message) message even when early_write succeeds on server side. Why does server wait to finish the handshake. I know it waits because I see client sending encrypted messages after server hello message before my intended application data gets sent from server. These encrypted messages from the client side are the usual messages from the client side for handshake completion.

3) Also, the performance of TLS 1.3 using early data or resumption is worse than TLS 1.2 resumption on LAN. I see on wire-shark that encrypted messages get exchanged in TLS 1.3 during handshake which are plaintext in TLS 1.2. I think that causes extra latency. So can we say that TLS 1.3 resumption is not recommended for LAN for performance enhancement when compared with TLS 1.2 resumption. On WAN, I see TLS 1.3 resumption at par with TLS 1.2 resumption and full handshake better for TLS 1.3.

Thanks
Best regards,
Neetish












> But then how can that data be read on the client side since
> read_early_data api is invalid on client side ?

0.5 RTT data is sent from the server to an unauthenticated client. At
this point in the process the server has sent all of its messages
(including its Certificate/CertificateVerify/Finished messages) but it
has not received the Client Finished or any client
Certificate/CertificateVerify if one is going to be sent.

From the client's perspective 0.5 RTT data is received *after* it has
processed the server's Certificate/CertificateVerify/Finished messages),
and after it has sent its own Finished (and
Certificate/CertificateVerify if appropriate). In other words from the
client's perspective the server is fully authenticated and 0.5 RTT data
is indistinguishable from post-handshake data. Just use SSL_read() as
normal to receive it.

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: session resumption tls1.2/tls1.3

OpenSSL - User mailing list
[Matt's reply is likely to be high latency]

On 07/24/2017 08:53 PM, Neetish Pathak wrote:


On Wed, Jul 19, 2017 at 2:27 AM, Matt Caswell <[hidden email]> wrote:


On 18/07/17 22:27, Neetish Pathak wrote:
> 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.

That is correct, and is as documented on this page:

https://www.openssl.org/docs/manmaster/man3/SSL_write_early_data.html


Thanks Matt
To send 0.5 RTT data I m sending the early_data from the server side just after the early_read data. But when I see the wire-shark logs, I see that the server data is sent only once the complete handshake has taken place. (which is the same as using SSL_write after SSL_accept).
I am performing following steps on client and server respectively as per understanding developed from previous discussions

Pseudocode for client

tcp_connect

write_early(data)

ssl_connect

if(early_data_write_failed){
      ssl_write(data)
}

ssl_read


Pseudocode for server

tcp_accept

read_early{

     if(read_early_success){
          write_early(data)
      }
}

ssl_accept

if(read_early_fail){
    ssl_read
    ssl_write(data)
}


I am measuring latency on the client side from TCP connection start  till it completes the read (ssl_read returns) (analogues to making a request from client and reading response).
Please suggest what may be going wrong basically with these queries

1) Why is there no difference (or negligible) in latencies when i use early write and then later ssl_read compared to when I execute normal write/read on the client side


Maybe I misunderstand the question, but isn't this is just a natural consequence of the server (mis)behavior in (2)?

2) Why does the server not send data (for early write) after the server Hello(and other encrypted message) message even when early_write succeeds on server side. Why does server wait to finish the handshake. I know it waits because I see client sending encrypted messages after server hello message before my intended application data gets sent from server. These encrypted messages from the client side are the usual messages from the client side for handshake completion.


From a quick look through the state machine code, this is supposed to work.  But someone would probably have to instrument the code (e.g., with printf) to tell why the delay is being introduced.  I don't think I have the availability to do so in the near future, myself.

3) Also, the performance of TLS 1.3 using early data or resumption is worse than TLS 1.2 resumption on LAN. I see on wire-shark that encrypted messages get exchanged in TLS 1.3 during handshake which are plaintext in TLS 1.2. I think that causes extra latency. So can we say that TLS 1.3 resumption is not recommended for LAN for performance enhancement when compared with TLS 1.2 resumption. On WAN, I see TLS 1.3 resumption at par with TLS 1.2 resumption and full handshake better for TLS 1.3.


It seems like it hasn't really sunk in for you that TLS 1.3 is a seriously different protocol than TLS 1.2, and it provides stronger security properties, remediating weaknesses of TLS 1.2.  So no, we should not recommend TLS 1.2 resumption on the LAN -- we should recommend the more secure option!  If you continue to believe that latency trumps everything else, you could experiment with SSL_OP_ALLOW_NO_DHE_KEX to cut out some of the heavier-weight asymmetric crypto, though it looks like you'd want to patch ssl/statem/extensions_clnt.c to not send TLSEXT_KEX_MODE_KE_DHE, as I don't see a way to configure the server to prefer the non-DHE PSK key exchange.

-Ben

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: session resumption tls1.2/tls1.3

neetish


Thanks Ben for your reply

On Tue, Jul 25, 2017 at 6:11 AM, Benjamin Kaduk <[hidden email]> wrote:
[Matt's reply is likely to be high latency]


On 07/24/2017 08:53 PM, Neetish Pathak wrote:


On Wed, Jul 19, 2017 at 2:27 AM, Matt Caswell <[hidden email]> wrote:


On 18/07/17 22:27, Neetish Pathak wrote:
> 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.

That is correct, and is as documented on this page:

https://www.openssl.org/docs/manmaster/man3/SSL_write_early_data.html


Thanks Matt
To send 0.5 RTT data I m sending the early_data from the server side just after the early_read data. But when I see the wire-shark logs, I see that the server data is sent only once the complete handshake has taken place. (which is the same as using SSL_write after SSL_accept).
I am performing following steps on client and server respectively as per understanding developed from previous discussions

Pseudocode for client

tcp_connect

write_early(data)

ssl_connect

if(early_data_write_failed){
      ssl_write(data)
}

ssl_read


Pseudocode for server

tcp_accept

read_early{

     if(read_early_success){
          write_early(data)
      }
}

ssl_accept

if(read_early_fail){
    ssl_read
    ssl_write(data)
}


I am measuring latency on the client side from TCP connection start  till it completes the read (ssl_read returns) (analogues to making a request from client and reading response).
Please suggest what may be going wrong basically with these queries

1) Why is there no difference (or negligible) in latencies when i use early write and then later ssl_read compared to when I execute normal write/read on the client side


Maybe I misunderstand the question, but isn't this is just a natural consequence of the server (mis)behavior in (2)?


Yes, this is right, the server misbehavior is causing this.
 


2) Why does the server not send data (for early write) after the server Hello(and other encrypted message) message even when early_write succeeds on server side. Why does server wait to finish the handshake. I know it waits because I see client sending encrypted messages after server hello message before my intended application data gets sent from server. These encrypted messages from the client side are the usual messages from the client side for handshake completion.


From a quick look through the state machine code, this is supposed to work.  But someone would probably have to instrument the code (e.g., with printf) to tell why the delay is being introduced.  I don't think I have the availability to do so in the near future, myself.


I see that the application data is not being sent from server to an unauthenticated client. The server is sending data only after receiving some encrypted message which I believe is the EndOfEarlyData and Finished messages. Following is  a dump of wireshark logs for the communication with early data enabled. I also tried with some logs in Openssl libraries, I see early data gets written from server side when write_early_data is called. Internally SSL_write_ex is called which completes write and handshake. But I am not sure why application data is not actually pushed from the server side. It is waiting for the Client finished message. 
I have disabled Nagle's algo during this operation.

Client port is 56806 and server port is 12345


No.     Time           Source                Destination           Protocol Length Info
    207 18.380298      ::1                   ::1                   TLSv1.3  956    Client Hello                   ----------------- Client Hello


No.     Time           Source                Destination           Protocol Length Info
    208 18.380335      ::1                   ::1                   TLSv1.3  2849   Application Data           ------------------Early Data from the client side (Intended Application Data)
Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq: 881, Ack: 1, Len: 2773

No.     Time           Source                Destination           Protocol Length Info
    211 18.380624      ::1                   ::1                   TLSv1.3  219    Server Hello, Application Data, Application Data . ------------Server Hello and (encrypted handshake message/extensions)
Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq: 1, Ack: 3654, Len: 143

No.     Time           Source                Destination           Protocol Length Info
    213 18.380819      ::1                   ::1                   TLSv1.3  160    Application Data, Application Data    ------Encrypted handshake msg from client (I believe they are end early data and finished)
Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq: 3654, Ack: 144, Len: 84


No.     Time           Source                Destination           Protocol Length Info
    215 18.381122      ::1                   ::1                   TLSv1.3  762    Application Data
Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq: 144, Ack: 3738, Len: 686   -----I don't know why this application data is sent from server. My guess is this is session info


No.     Time           Source                Destination           Protocol Length Info
    217 18.381210      ::1                   ::1                   TLSv1.3  9917   Application Data          ----------Intended Application Data that was intended to be early data 
Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq: 830, Ack: 3738, Len: 9841

No.     Time           Source                Destination           Protocol Length Info
    219 18.381308      ::1                   ::1                   TLSv1.3  100    Application Data .             ---------Application Data from client (I also see this application data sent everytime, not sure why)
Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq: 3738, Ack: 10671, Len: 24


No.     Time           Source                Destination           Protocol Length Info
    220 18.381309      ::1                   ::1                   TLSv1.3  100    Application Data .  ---------Application Data from server (I also see this application data sent everytime, not sure why)
Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq: 10671, Ack: 3738, Len: 24

Please provide any comments if you have or how I should go about debugging it. Correct me if I am doing it wrong


 


3) Also, the performance of TLS 1.3 using early data or resumption is worse than TLS 1.2 resumption on LAN. I see on wire-shark that encrypted messages get exchanged in TLS 1.3 during handshake which are plaintext in TLS 1.2. I think that causes extra latency. So can we say that TLS 1.3 resumption is not recommended for LAN for performance enhancement when compared with TLS 1.2 resumption. On WAN, I see TLS 1.3 resumption at par with TLS 1.2 resumption and full handshake better for TLS 1.3.


It seems like it hasn't really sunk in for you that TLS 1.3 is a seriously different protocol than TLS 1.2, and it provides stronger security properties, remediating weaknesses of TLS 1.2.  So no, we should not recommend TLS 1.2 resumption on the LAN -- we should recommend the more secure option!  If you continue to believe that latency trumps everything else, you could experiment with SSL_OP_ALLOW_NO_DHE_KEX to cut out some of the heavier-weight asymmetric crypto, though it looks like you'd want to patch ssl/statem/extensions_clnt.c to not send TLSEXT_KEX_MODE_KE_DHE, as I don't see a way to configure the server to prefer the non-DHE PSK key exchange.


OK, I understand that, Thanks Ben. I think I got a small improvement on latency by removing TLSEXT_KEX_MODE_KE_DHE. But I also reckon that security comes first and hence it requires deliberation. 
 
 Thanks
BR,
Neetish

-Ben


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: session resumption tls1.2/tls1.3

OpenSSL - User mailing list
On 07/25/2017 06:05 PM, Neetish Pathak wrote:


Please provide any comments if you have or how I should go about debugging it. Correct me if I am doing it wrong


I don't really have any good suggestions for debugging it.  It might be interesting to run in a debugger and collect full backtraces on each entry to ssl3_write_pending() on the server.

-Ben

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: session resumption tls1.2/tls1.3

Matt Caswell-2
In reply to this post by neetish
Apologies for the delayed response - I've been away on holiday. Comments
inserted below.

Matt


On 26/07/17 00:05, Neetish Pathak wrote:

>>     *Pseudocode for server*
>>     *
>>     *
>>     tcp_accept
>>     *
>>     *
>>     read_early{
>>
>>          if(read_early_success){
>>               write_early(data)
>>           }
>>     }

There is a bit of complexity here (covered in the docs), i.e.
SSL_read_early_data() may return SSL_READ_EARLY_DATA_SUCCESS or
SSL_READ_EARLY_DATA_FINISH. In the latter case this is still a success,
but the server may or may not be able to write early data. I assume that
you have covered that in your actual code and it's just skimmed over
here in your pseudo code.


>>     2) Why does the server not send data (for early write) after the
>>     server Hello(and other encrypted message) message even when
>>     early_write succeeds on server side. Why does server wait to
>>     finish the handshake. I know it waits because I see client sending
>>     encrypted messages after server hello message before my intended
>>     application data gets sent from server. These encrypted messages
>>     from the client side are the usual messages from the client side
>>     for handshake completion.
>>
>
>     From a quick look through the state machine code, this is supposed
>     to work.  But someone would probably have to instrument the code
>     (e.g., with printf) to tell why the delay is being introduced.  I
>     don't think I have the availability to do so in the near future, myself.
>
>
>
> I see that the application data is not being sent from server to an
> unauthenticated client. The server is sending data only after receiving
> some encrypted message which I believe is the EndOfEarlyData and
> Finished messages. Following is  a dump of wireshark logs for the
> communication with early data enabled. I also tried with some logs in
> Openssl libraries, I see early data gets written from server side when
> write_early_data is called. Internally SSL_write_ex is called which
> completes write and handshake. But I am not sure why application data is
> not actually pushed from the server side. It is waiting for the Client
> finished message.
> I have disabled Nagle's algo during this operation.

Can you confirm whether you have disabled Nagle's algo on both the
client *and* the server?`


>
> Client port is 56806 and server port is 12345
>
>
> No.     Time           Source                Destination          
> Protocol Length Info
>     207 18.380298      ::1                   ::1                  
> TLSv1.3  956    Client Hello                  ----------------- Client Hello
>
>
> No.     Time           Source                Destination          
> Protocol Length Info
>     208 18.380335      ::1                   ::1                  
> TLSv1.3  2849   Application Data          ------------------*Early Data
> from the client side (Intended Application Data)*
> Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq:
> 881, Ack: 1, Len: 2773
>
> No.     Time           Source                Destination          
> Protocol Length Info
>     211 18.380624      ::1                   ::1                  
> TLSv1.3  219    Server Hello, Application Data, Application Data .
> ------------Server Hello and (encrypted handshake message/extensions)
> Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq: 1,
> Ack: 3654, Len: 143
>
> No.     Time           Source                Destination          
> Protocol Length Info
>     213 18.380819      ::1                   ::1                  
> TLSv1.3  160    Application Data, Application Data    ------Encrypted
> handshake msg from client (*I believe they are end early data and finished*)
> Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq:
> 3654, Ack: 144, Len: 84
>
>
> No.     Time           Source                Destination          
> Protocol Length Info
>     215 18.381122      ::1                   ::1                  
> TLSv1.3  762    Application Data
> Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq:
> 144, Ack: 3738, Len: 686   -----I don't know why this application data
> is sent from server. My guess is this is session info

It could be the NewSessionTicket message going from the server to the
client. But if so that is a little strange. The NST message is only sent
after the handshake is complete (so no more early data is possible). At
this point SSL_read_early_data() should have returned
SSL_READ_EARLY_DATA_SUCCESS, SSL_is_init_finished() will return true,
and any calls to SSL_write_early_data() will fail.



>
>
> No.     Time           Source                Destination          
> Protocol Length Info
>     217 18.381210      ::1                   ::1                  
> TLSv1.3  9917   Application Data          ----------*Intended
> Application Data that was intended to be early data *
> Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq:
> 830, Ack: 3738, Len: 9841
>
> No.     Time           Source                Destination          
> Protocol Length Info
>     219 18.381308      ::1                   ::1                  
> TLSv1.3  100    Application Data .             ---------Application Data
> from client (I also see this application data sent everytime, not sure why)
> Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq:
> 3738, Ack: 10671, Len: 24
>
>
> No.     Time           Source                Destination          
> Protocol Length Info
>     220 18.381309      ::1                   ::1                  
> TLSv1.3  100    Application Data .  ---------Application Data from
> server (I also see this application data sent everytime, not sure why)

Perhaps these are close_notify alerts? Are you shutting down the
connection cleanly at this point?

Matt
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: session resumption tls1.2/tls1.3

Matt Caswell-2


On 31/07/17 17:43, Matt Caswell wrote:
> It could be the NewSessionTicket message going from the server to the
> client. But if so that is a little strange. The NST message is only sent
> after the handshake is complete (so no more early data is possible). At
> this point SSL_read_early_data() should have returned
> SSL_READ_EARLY_DATA_SUCCESS, SSL_is_init_finished() will return true,

I meant to say SSL_read_early_data() should have returned
SSL_READ_EARLY_DATA_FINISH.

Matt
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: session resumption tls1.2/tls1.3

neetish
In reply to this post by Matt Caswell-2


On Mon, Jul 31, 2017 at 9:43 AM, Matt Caswell <[hidden email]> wrote:
Apologies for the delayed response - I've been away on holiday. Comments
inserted below.


No problem thanks for the replies 

Matt


On 26/07/17 00:05, Neetish Pathak wrote:
>>     *Pseudocode for server*
>>     *
>>     *
>>     tcp_accept
>>     *
>>     *
>>     read_early{
>>
>>          if(read_early_success){
>>               write_early(data)
>>           }
>>     }

There is a bit of complexity here (covered in the docs), i.e.
SSL_read_early_data() may return SSL_READ_EARLY_DATA_SUCCESS or
SSL_READ_EARLY_DATA_FINISH. In the latter case this is still a success,
but the server may or may not be able to write early data. I assume that
you have covered that in your actual code and it's just skimmed over
here in your pseudo code.


So, I consider read_early_sucess when  SSL_read_early_data() returns SSL_READ_EARLY_DATA_FINISH. Also, I check that early data was accepted before declaring success. Look at the case checks below

case SSL_READ_EARLY_DATA_SUCCESS:

        totalBytes += readBytes;

         break;


case SSL_READ_EARLY_DATA_FINISH:

       totalBytes += readBytes;

       if (SSL_EARLY_DATA_ACCEPTED == SSL_get_early_data_status(this->conn) && totalBytes > 0) {

             readBuf = string(readBuffer);

             return SUCCESS;

      }


So, are you suggesting that early data may not be written from the server side if SSL_READ_EARLY_DATA_FINISH is received. Should I try writing before that (as in when SSL_READ_EARLY_DATA_SUCCESS is received )



>>     2) Why does the server not send data (for early write) after the
>>     server Hello(and other encrypted message) message even when
>>     early_write succeeds on server side. Why does server wait to
>>     finish the handshake. I know it waits because I see client sending
>>     encrypted messages after server hello message before my intended
>>     application data gets sent from server. These encrypted messages
>>     from the client side are the usual messages from the client side
>>     for handshake completion.
>>
>
>     From a quick look through the state machine code, this is supposed
>     to work.  But someone would probably have to instrument the code
>     (e.g., with printf) to tell why the delay is being introduced.  I
>     don't think I have the availability to do so in the near future, myself.
>
>
>
> I see that the application data is not being sent from server to an
> unauthenticated client. The server is sending data only after receiving
> some encrypted message which I believe is the EndOfEarlyData and
> Finished messages. Following is  a dump of wireshark logs for the
> communication with early data enabled. I also tried with some logs in
> Openssl libraries, I see early data gets written from server side when
> write_early_data is called. Internally SSL_write_ex is called which
> completes write and handshake. But I am not sure why application data is
> not actually pushed from the server side. It is waiting for the Client
> finished message.
> I have disabled Nagle's algo during this operation.

Can you confirm whether you have disabled Nagle's algo on both the
client *and* the server?`


Nagle's algorithm is disabled on both the client and the server side.


>
> Client port is 56806 and server port is 12345
>
>
> No.     Time           Source                Destination
> Protocol Length Info
>     207 18.380298      ::1                   ::1
> TLSv1.3  956    Client Hello                  ----------------- Client Hello
>
>
> No.     Time           Source                Destination
> Protocol Length Info
>     208 18.380335      ::1                   ::1
> TLSv1.3  2849   Application Data          ------------------*Early Data
> from the client side (Intended Application Data)*
> Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq:
> 881, Ack: 1, Len: 2773
>
> No.     Time           Source                Destination
> Protocol Length Info
>     211 18.380624      ::1                   ::1
> TLSv1.3  219    Server Hello, Application Data, Application Data .
> ------------Server Hello and (encrypted handshake message/extensions)
> Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq: 1,
> Ack: 3654, Len: 143
>
> No.     Time           Source                Destination
> Protocol Length Info
>     213 18.380819      ::1                   ::1
> TLSv1.3  160    Application Data, Application Data    ------Encrypted
> handshake msg from client (*I believe they are end early data and finished*)
> Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq:
> 3654, Ack: 144, Len: 84
>
>
> No.     Time           Source                Destination
> Protocol Length Info
>     215 18.381122      ::1                   ::1
> TLSv1.3  762    Application Data
> Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq:
> 144, Ack: 3738, Len: 686   -----I don't know why this application data
> is sent from server. My guess is this is session info

It could be the NewSessionTicket message going from the server to the
client. But if so that is a little strange. The NST message is only sent
after the handshake is complete (so no more early data is possible). At
this point SSL_read_early_data() should have returned
SSL_READ_EARLY_DATA_SUCCESS, SSL_is_init_finished() will return true,
and any calls to SSL_write_early_data() will fail.

Yes, here the handshake is completed. Will the new session ticket be sent each time after the handshake? In theTLS 1.3 draft, it is mentioned that new session tickets may be sent after server receives Finished from the client and it creates a unique association between the ticket value and a secret PSK derived from the resumption master secret. 
But looks like, I am receiving new session ticket every-time. So, as per the implementation, new session ticket is a must I guess. Am I right? When will I not receive new session ticket in TLS 1.3?

Also, I believe it is different than how new session ticket works in TLS 1.2 where it was sent only once to share the encrypted ticket from the server side when the client indicates support for session tickets.

   


>
>
> No.     Time           Source                Destination
> Protocol Length Info
>     217 18.381210      ::1                   ::1
> TLSv1.3  9917   Application Data          ----------*Intended
> Application Data that was intended to be early data *
> Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq:
> 830, Ack: 3738, Len: 9841
>
> No.     Time           Source                Destination
> Protocol Length Info
>     219 18.381308      ::1                   ::1
> TLSv1.3  100    Application Data .             ---------Application Data
> from client (I also see this application data sent everytime, not sure why)
> Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq:
> 3738, Ack: 10671, Len: 24
>
>
> No.     Time           Source                Destination
> Protocol Length Info
>     220 18.381309      ::1                   ::1
> TLSv1.3  100    Application Data .  ---------Application Data from
> server (I also see this application data sent everytime, not sure why)

Perhaps these are close_notify alerts? Are you shutting down the
connection cleanly at this point?

I am shutting down the connection from the client side. Server is up all the time for any new connection.

Thanks
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: session resumption tls1.2/tls1.3

Matt Caswell-2


On 31/07/17 20:37, Neetish Pathak wrote:

>     On 26/07/17 00:05, Neetish Pathak wrote:
>     >>     *Pseudocode for server*
>     >>     *
>     >>     *
>     >>     tcp_accept
>     >>     *
>     >>     *
>     >>     read_early{
>     >>
>     >>          if(read_early_success){
>     >>               write_early(data)
>     >>           }
>     >>     }
>
>     There is a bit of complexity here (covered in the docs), i.e.
>     SSL_read_early_data() may return SSL_READ_EARLY_DATA_SUCCESS or
>     SSL_READ_EARLY_DATA_FINISH. In the latter case this is still a success,
>     but the server may or may not be able to write early data. I assume that
>     you have covered that in your actual code and it's just skimmed over
>     here in your pseudo code.
>
>
>
> So, I consider read_early_sucess when  SSL_read_early_data() returns
> SSL_READ_EARLY_DATA_FINISH. Also, I check that early data was accepted
> before declaring success. Look at the case checks below
>
> *case* SSL_READ_EARLY_DATA_SUCCESS:
>
>         totalBytes += readBytes;
>
> *         break*;
>
> *
> *
>
> *case* SSL_READ_EARLY_DATA_FINISH:
>
>        totalBytes += readBytes;
>
> *       if* (SSL_EARLY_DATA_ACCEPTED ==
> SSL_get_early_data_status(*this*->conn) && totalBytes > 0) {
>
>              readBuf = string(readBuffer);
>
> *             return* SUCCESS;
>
>       }
>
>
> So, are you suggesting that early data may not be written from the
> server side if SSL_READ_EARLY_DATA_FINISH is received. Should I try
> writing before that (as in when SSL_READ_EARLY_DATA_SUCCESS is received )


SSL_READ_EARLY_DATA_FINISH is not returned until we have seen the
EndOfEarlyData message. Often (but not always - dependent on the
implementation) the client Finished message is also in the same packet
which OpenSSL will immediately try and process. As soon as it has done
so the handshake is complete and it is too late for the server to write
early data. Calls to SSL_write_early_data() by the server at this point
should fail (do you not see this???).

You should write early data on the server side as soon as
SSL_READ_EARLY_DATA_SUCCESS is received.



>     > No.     Time           Source                Destination
>     > Protocol Length Info
>     >     215 18.381122      ::1                   ::1
>     > TLSv1.3  762    Application Data
>     > Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq:
>     > 144, Ack: 3738, Len: 686   -----I don't know why this application data
>     > is sent from server. My guess is this is session info
>
>     It could be the NewSessionTicket message going from the server to the
>     client. But if so that is a little strange. The NST message is only sent
>     after the handshake is complete (so no more early data is possible). At
>     this point SSL_read_early_data() should have returned
>     SSL_READ_EARLY_DATA_SUCCESS, SSL_is_init_finished() will return true,
>     and any calls to SSL_write_early_data() will fail.
>
>
> Yes, here the handshake is completed. Will the new session ticket be
> sent each time after the handshake? In theTLS 1.3 draft, it is mentioned
> that new session tickets may be sent after server receives Finished from
> the client and it creates a unique association between the ticket value
> and a secret PSK derived from the resumption master secret.
> But looks like, I am receiving new session ticket every-time. So, as per
> the implementation, new session ticket is a must I guess. Am I right?
> When will I not receive new session ticket in TLS 1.3?

The OpenSSL implementation *always* sends a NewSessionTicket message
immediately after the handshake is complete. This is not required, but
is allowed by the spec. Currently there is no way to disable this
behaviour. Do you need/want it (if so, why)?

>
> Also, I believe it is different than how new session ticket works in TLS
> 1.2 where it was sent only once to share the encrypted ticket from the
> server side when the client indicates support for session tickets.

Yes, TLSv1.2 session tickets share the same name and have a similar
purpose, but are otherwise *completely* different to TLSv1.3 session
tickets.


>     >
>     > No.     Time           Source                Destination
>     > Protocol Length Info
>     >     217 18.381210      ::1                   ::1
>     > TLSv1.3  9917   Application Data          ----------*Intended
>     > Application Data that was intended to be early data *
>     > Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq:
>     > 830, Ack: 3738, Len: 9841
>     >
>     > No.     Time           Source                Destination
>     > Protocol Length Info
>     >     219 18.381308      ::1                   ::1
>     > TLSv1.3  100    Application Data .             ---------Application Data
>     > from client (I also see this application data sent everytime, not sure why)
>     > Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq:
>     > 3738, Ack: 10671, Len: 24
>     >
>     >
>     > No.     Time           Source                Destination
>     > Protocol Length Info
>     >     220 18.381309      ::1                   ::1
>     > TLSv1.3  100    Application Data .  ---------Application Data from
>     > server (I also see this application data sent everytime, not sure why)
>
>     Perhaps these are close_notify alerts? Are you shutting down the
>     connection cleanly at this point?
>
>
> I am shutting down the connection from the client side. Server is up all
> the time for any new connection.

As soon as you call SSL_shutdown() then a close_notify alert is sent.
Typically you do that on both the client and the server sides which
seems to match your wireshark trace.

Matt

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: session resumption tls1.2/tls1.3

neetish


On Mon, Jul 31, 2017 at 2:00 PM, Matt Caswell <[hidden email]> wrote:


On 31/07/17 20:37, Neetish Pathak wrote:
>     On 26/07/17 00:05, Neetish Pathak wrote:
>     >>     *Pseudocode for server*
>     >>     *
>     >>     *
>     >>     tcp_accept
>     >>     *
>     >>     *
>     >>     read_early{
>     >>
>     >>          if(read_early_success){
>     >>               write_early(data)
>     >>           }
>     >>     }
>
>     There is a bit of complexity here (covered in the docs), i.e.
>     SSL_read_early_data() may return SSL_READ_EARLY_DATA_SUCCESS or
>     SSL_READ_EARLY_DATA_FINISH. In the latter case this is still a success,
>     but the server may or may not be able to write early data. I assume that
>     you have covered that in your actual code and it's just skimmed over
>     here in your pseudo code.
>
>
>
> So, I consider read_early_sucess when  SSL_read_early_data() returns
> SSL_READ_EARLY_DATA_FINISH. Also, I check that early data was accepted
> before declaring success. Look at the case checks below
>
> *case* SSL_READ_EARLY_DATA_SUCCESS:
>
>         totalBytes += readBytes;
>
> *         break*;
>
> *
> *
>
> *case* SSL_READ_EARLY_DATA_FINISH:
>
>        totalBytes += readBytes;
>
> *       if* (SSL_EARLY_DATA_ACCEPTED ==
> SSL_get_early_data_status(*this*->conn) && totalBytes > 0) {
>
>              readBuf = string(readBuffer);
>
> *             return* SUCCESS;
>
>       }
>
>
> So, are you suggesting that early data may not be written from the
> server side if SSL_READ_EARLY_DATA_FINISH is received. Should I try
> writing before that (as in when SSL_READ_EARLY_DATA_SUCCESS is received )


SSL_READ_EARLY_DATA_FINISH is not returned until we have seen the
EndOfEarlyData message. Often (but not always - dependent on the
implementation) the client Finished message is also in the same packet
which OpenSSL will immediately try and process. As soon as it has done
so the handshake is complete and it is too late for the server to write
early data. Calls to SSL_write_early_data() by the server at this point
should fail (do you not see this???).

You should write early data on the server side as soon as
SSL_READ_EARLY_DATA_SUCCESS is received.


Yes, this is what I tried and it worked. Thanks for the clarification 



>     > No.     Time           Source                Destination
>     > Protocol Length Info
>     >     215 18.381122      ::1                   ::1
>     > TLSv1.3  762    Application Data
>     > Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq:
>     > 144, Ack: 3738, Len: 686   -----I don't know why this application data
>     > is sent from server. My guess is this is session info
>
>     It could be the NewSessionTicket message going from the server to the
>     client. But if so that is a little strange. The NST message is only sent
>     after the handshake is complete (so no more early data is possible). At
>     this point SSL_read_early_data() should have returned
>     SSL_READ_EARLY_DATA_SUCCESS, SSL_is_init_finished() will return true,
>     and any calls to SSL_write_early_data() will fail.
>
>
> Yes, here the handshake is completed. Will the new session ticket be
> sent each time after the handshake? In theTLS 1.3 draft, it is mentioned
> that new session tickets may be sent after server receives Finished from
> the client and it creates a unique association between the ticket value
> and a secret PSK derived from the resumption master secret.
> But looks like, I am receiving new session ticket every-time. So, as per
> the implementation, new session ticket is a must I guess. Am I right?
> When will I not receive new session ticket in TLS 1.3?

The OpenSSL implementation *always* sends a NewSessionTicket message
immediately after the handshake is complete. This is not required, but
is allowed by the spec. Currently there is no way to disable this
behaviour. Do you need/want it (if so, why)?

No, I do not need to disable it per se. The handshake completion at the client side is independent of the newsession ticket coming from the server side if I am correct. So the handshake operation (specifically SSL_connect) will return even if new session ticket has not arrived from the server. I was asking why new session ticket is needed during the resumption handshake. Isn't it just an overhead? 
 

>
> Also, I believe it is different than how new session ticket works in TLS
> 1.2 where it was sent only once to share the encrypted ticket from the
> server side when the client indicates support for session tickets.

Yes, TLSv1.2 session tickets share the same name and have a similar
purpose, but are otherwise *completely* different to TLSv1.3 session
tickets.

Understood 


>     >
>     > No.     Time           Source                Destination
>     > Protocol Length Info
>     >     217 18.381210      ::1                   ::1
>     > TLSv1.3  9917   Application Data          ----------*Intended
>     > Application Data that was intended to be early data *
>     > Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq:
>     > 830, Ack: 3738, Len: 9841
>     >
>     > No.     Time           Source                Destination
>     > Protocol Length Info
>     >     219 18.381308      ::1                   ::1
>     > TLSv1.3  100    Application Data .             ---------Application Data
>     > from client (I also see this application data sent everytime, not sure why)
>     > Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq:
>     > 3738, Ack: 10671, Len: 24
>     >
>     >
>     > No.     Time           Source                Destination
>     > Protocol Length Info
>     >     220 18.381309      ::1                   ::1
>     > TLSv1.3  100    Application Data .  ---------Application Data from
>     > server (I also see this application data sent everytime, not sure why)
>
>     Perhaps these are close_notify alerts? Are you shutting down the
>     connection cleanly at this point?
>
>
> I am shutting down the connection from the client side. Server is up all
> the time for any new connection.

As soon as you call SSL_shutdown() then a close_notify alert is sent.
Typically you do that on both the client and the server sides which
seems to match your wireshark trace.

OK Thanks 

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: session resumption tls1.2/tls1.3

neetish


On Tue, Aug 1, 2017 at 10:46 AM, Neetish Pathak <[hidden email]> wrote:


On Mon, Jul 31, 2017 at 2:00 PM, Matt Caswell <[hidden email]> wrote:


On 31/07/17 20:37, Neetish Pathak wrote:
>     On 26/07/17 00:05, Neetish Pathak wrote:
>     >>     *Pseudocode for server*
>     >>     *
>     >>     *
>     >>     tcp_accept
>     >>     *
>     >>     *
>     >>     read_early{
>     >>
>     >>          if(read_early_success){
>     >>               write_early(data)
>     >>           }
>     >>     }
>
>     There is a bit of complexity here (covered in the docs), i.e.
>     SSL_read_early_data() may return SSL_READ_EARLY_DATA_SUCCESS or
>     SSL_READ_EARLY_DATA_FINISH. In the latter case this is still a success,
>     but the server may or may not be able to write early data. I assume that
>     you have covered that in your actual code and it's just skimmed over
>     here in your pseudo code.
>
>
>
> So, I consider read_early_sucess when  SSL_read_early_data() returns
> SSL_READ_EARLY_DATA_FINISH. Also, I check that early data was accepted
> before declaring success. Look at the case checks below
>
> *case* SSL_READ_EARLY_DATA_SUCCESS:
>
>         totalBytes += readBytes;
>
> *         break*;
>
> *
> *
>
> *case* SSL_READ_EARLY_DATA_FINISH:
>
>        totalBytes += readBytes;
>
> *       if* (SSL_EARLY_DATA_ACCEPTED ==
> SSL_get_early_data_status(*this*->conn) && totalBytes > 0) {
>
>              readBuf = string(readBuffer);
>
> *             return* SUCCESS;
>
>       }
>
>
> So, are you suggesting that early data may not be written from the
> server side if SSL_READ_EARLY_DATA_FINISH is received. Should I try
> writing before that (as in when SSL_READ_EARLY_DATA_SUCCESS is received )


SSL_READ_EARLY_DATA_FINISH is not returned until we have seen the
EndOfEarlyData message. Often (but not always - dependent on the
implementation) the client Finished message is also in the same packet
which OpenSSL will immediately try and process. As soon as it has done
so the handshake is complete and it is too late for the server to write
early data. Calls to SSL_write_early_data() by the server at this point
should fail (do you not see this???).

You should write early data on the server side as soon as
SSL_READ_EARLY_DATA_SUCCESS is received.


Yes, this is what I tried and it worked. Thanks for the clarification. Also, this point is not very clear from the man page on when the write early data be sent from the server side (after SUCCESS or FINISH). Can it be included?



>     > No.     Time           Source                Destination
>     > Protocol Length Info
>     >     215 18.381122      ::1                   ::1
>     > TLSv1.3  762    Application Data
>     > Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq:
>     > 144, Ack: 3738, Len: 686   -----I don't know why this application data
>     > is sent from server. My guess is this is session info
>
>     It could be the NewSessionTicket message going from the server to the
>     client. But if so that is a little strange. The NST message is only sent
>     after the handshake is complete (so no more early data is possible). At
>     this point SSL_read_early_data() should have returned
>     SSL_READ_EARLY_DATA_SUCCESS, SSL_is_init_finished() will return true,
>     and any calls to SSL_write_early_data() will fail.
>
>
> Yes, here the handshake is completed. Will the new session ticket be
> sent each time after the handshake? In theTLS 1.3 draft, it is mentioned
> that new session tickets may be sent after server receives Finished from
> the client and it creates a unique association between the ticket value
> and a secret PSK derived from the resumption master secret.
> But looks like, I am receiving new session ticket every-time. So, as per
> the implementation, new session ticket is a must I guess. Am I right?
> When will I not receive new session ticket in TLS 1.3?

The OpenSSL implementation *always* sends a NewSessionTicket message
immediately after the handshake is complete. This is not required, but
is allowed by the spec. Currently there is no way to disable this
behaviour. Do you need/want it (if so, why)?

No, I do not need to disable it per se. The handshake completion at the client side is independent of the newsession ticket coming from the server side if I am correct. So the handshake operation (specifically SSL_connect) will return even if new session ticket has not arrived from the server. I was asking why new session ticket is needed during the resumption handshake. Isn't it just an overhead? 
 

>
> Also, I believe it is different than how new session ticket works in TLS
> 1.2 where it was sent only once to share the encrypted ticket from the
> server side when the client indicates support for session tickets.

Yes, TLSv1.2 session tickets share the same name and have a similar
purpose, but are otherwise *completely* different to TLSv1.3 session
tickets.

Understood 


>     >
>     > No.     Time           Source                Destination
>     > Protocol Length Info
>     >     217 18.381210      ::1                   ::1
>     > TLSv1.3  9917   Application Data          ----------*Intended
>     > Application Data that was intended to be early data *
>     > Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq:
>     > 830, Ack: 3738, Len: 9841
>     >
>     > No.     Time           Source                Destination
>     > Protocol Length Info
>     >     219 18.381308      ::1                   ::1
>     > TLSv1.3  100    Application Data .             ---------Application Data
>     > from client (I also see this application data sent everytime, not sure why)
>     > Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq:
>     > 3738, Ack: 10671, Len: 24
>     >
>     >
>     > No.     Time           Source                Destination
>     > Protocol Length Info
>     >     220 18.381309      ::1                   ::1
>     > TLSv1.3  100    Application Data .  ---------Application Data from
>     > server (I also see this application data sent everytime, not sure why)
>
>     Perhaps these are close_notify alerts? Are you shutting down the
>     connection cleanly at this point?
>
>
> I am shutting down the connection from the client side. Server is up all
> the time for any new connection.

As soon as you call SSL_shutdown() then a close_notify alert is sent.
Typically you do that on both the client and the server sides which
seems to match your wireshark trace.

OK Thanks 

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
Loading...