session resumption tls1.2/tls1.3

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 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
Loading...