Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

On Wed, Jun 21, 2017 at 3:11 AM, Matt Caswell  wrote:

>
>
> On 21/06/17 00:38, Neetish Pathak wrote:
> > I wanted to understand the replay attack vulnerability in case of enable
> > early data of TLS 1.3 while false start is secure in that respect as I
> > have read from https://github.com/openssl/openssl/issues/1541
> > So, with false start, the application data is sent from client after the
> > first leg of the handshake i.e. one round trip is complete, so the data
> > goes encrypted even though the handshake is not completed. In enable
> > early data mode in TLS 1.3 for 0-RTT for session resumption, the
> > application data is sent from the client along with the client hello
> > message. Does the application data in early data mode go as clear text ?
>
> No, it is encrypted using a traffic key derived from the PSK.
>
> > I assume this is also encrypted using the PSK because 0-RTT is only
> > applicable when PSK is available on the client side. How is it
> > vulnerable to replay attack. Please help me understand.
>
> The same PSK can be used multiple times. Because the traffic key for the
> early data is derived from the PSK, if you later re-use the PSK and send
> early data again then the same traffic key will be derived. This can be
> exploited by an attacker who can record the early data from an earlier
> session and replay it later. The server will think that the replayed
> data is a new connection and process the early data accordingly.
>
> Early data (aka 0-RTT data) can be dangerous if not used properly. For
> this reason the current TLSv1.3 draft makes this note:
>
>Protocols MUST NOT use 0-RTT data without a profile that defines its
>use.  That profile needs to identify which messages or interactions
>are safe to use with 0-RTT.  In addition, to avoid accidental misuse,
>implementations SHOULD NOT enable 0-RTT unless specifically
>requested.  Implementations SHOULD provide special functions for
>0-RTT data to ensure that an application is always aware that it is
>sending or receiving data that might be replayed.
>
>
> >
> > Is there any API available in OpenSSL for false start ?
>
> No, OpenSSL does not support false start. As an aside please note that
> false start only applies to <= TLSv1.2.


Thanks for your comments.

I need some direction on the doing server and client side authentication
during the handshake.

*1) For certificate sent from the server side, I am using*

SSL_CTX_load_verify_locations(ssl_ctx, CAFILE, NULL))   for loading
verification file *on the client side*

Where do I get a CAFILE in the above API. If the server is sending a self
signed certificate, what will be the CA file on the client side for
verification.


*2) For Client side authentication*

I am using SSL_CTX_use_PrivateKey_file and SSL_CTX_use_certificate file on
the client side to load the private key and the certificate.
I read that client side authentication will not kick off unless the server
sends CertificateRequest. I can use SSL_CTX_set_client_cert_cb() that sets
the client_cert_cb() callback to be called on CertificateRequest.

I am not sure how I can enable the server side to send CertificateRequest.
What is the API for that.
Should SSL_CTX_set_verify((ssl_ctx,SSL_VERIFY_PEER, NULL)) be used on
server side for sending the certificateRequest message. Please correct me ?

*3) Certificate request Message*
Also, what is the use of CertificateVerify message. Why does client need to
prove the ownership of private key for the public key sent previously in
the client certificate. I assume this is not happening when the server
sends the certificate. It doesn't prove the ownership of private key.Please
comment



Also, some guidance on a reference for understanding the authentication of
certificates will be appreciated


Thanks
Neetish


>
>
> Matt
>
> >
> > Thanks
> > Best regards,
> > Neetish
> >
> > On Tue, Jun 20, 2017 at 11:52 AM, Neetish Pathak  > > wrote:
> >
> > I Appreciate your response
> >
> > On Tue, Jun 20, 2017 at 2:09 AM, Matt Caswell  > > wrote:
> >
> >
> >
> > On 19/06/17 19:11, Neetish Pathak wrote:
> > > 2) Can you suggest some places to put a time stamp in OpenSSL
> code.
> >
> > I agree with Ben's responses to all your other questions. For
> this
> > question, I'm not sure what you are trying to achieve? Starting
> > before
> > SSL_accept/SSL_connect and finishing after they return should be
> > fine.
> > Or are you looking for a breakdown of where the time is going?
> >
> > Thanks Matt. I was asking for a breakdown since I was not sure
> > if the SSL_accept and SSL_connect just do the handshake or if
> > they are doing some other things that may impact latency and CPU
> > usage. Just wanted to be clear that calling SSL_connect  starts
> > 

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Matt Caswell]

On 21/06/17 00:38, Neetish Pathak wrote:
> I wanted to understand the replay attack vulnerability in case of enable
> early data of TLS 1.3 while false start is secure in that respect as I
> have read from https://github.com/openssl/openssl/issues/1541
> So, with false start, the application data is sent from client after the
> first leg of the handshake i.e. one round trip is complete, so the data
> goes encrypted even though the handshake is not completed. In enable
> early data mode in TLS 1.3 for 0-RTT for session resumption, the
> application data is sent from the client along with the client hello
> message. Does the application data in early data mode go as clear text ?

No, it is encrypted using a traffic key derived from the PSK.

> I assume this is also encrypted using the PSK because 0-RTT is only
> applicable when PSK is available on the client side. How is it
> vulnerable to replay attack. Please help me understand.

The same PSK can be used multiple times. Because the traffic key for the
early data is derived from the PSK, if you later re-use the PSK and send
early data again then the same traffic key will be derived. This can be
exploited by an attacker who can record the early data from an earlier
session and replay it later. The server will think that the replayed
data is a new connection and process the early data accordingly.

Early data (aka 0-RTT data) can be dangerous if not used properly. For
this reason the current TLSv1.3 draft makes this note:

   Protocols MUST NOT use 0-RTT data without a profile that defines its
   use.  That profile needs to identify which messages or interactions
   are safe to use with 0-RTT.  In addition, to avoid accidental misuse,
   implementations SHOULD NOT enable 0-RTT unless specifically
   requested.  Implementations SHOULD provide special functions for
   0-RTT data to ensure that an application is always aware that it is
   sending or receiving data that might be replayed.


> 
> Is there any API available in OpenSSL for false start ?

No, OpenSSL does not support false start. As an aside please note that
false start only applies to <= TLSv1.2.


Matt

> 
> Thanks
> Best regards,
> Neetish
> 
> On Tue, Jun 20, 2017 at 11:52 AM, Neetish Pathak  > wrote:
> 
> I Appreciate your response
> 
> On Tue, Jun 20, 2017 at 2:09 AM, Matt Caswell  > wrote:
> 
> 
> 
> On 19/06/17 19:11, Neetish Pathak wrote:
> > 2) Can you suggest some places to put a time stamp in OpenSSL code.
> 
> I agree with Ben's responses to all your other questions. For this
> question, I'm not sure what you are trying to achieve? Starting
> before
> SSL_accept/SSL_connect and finishing after they return should be
> fine.
> Or are you looking for a breakdown of where the time is going?
> 
> Thanks Matt. I was asking for a breakdown since I was not sure
> if the SSL_accept and SSL_connect just do the handshake or if
> they are doing some other things that may impact latency and CPU
> usage. Just wanted to be clear that calling SSL_connect  starts
> ClientHello , SSL_accept unblocks on receiving ClientHello and
> sends ServerHello, and both functions return after sending
> Finished message from their sides (i.e. client and server).
> 
> 
> 
>  
> 
> Matt
> 
> >
> > Thanks
> > Best Regards,
> > Neetish
> >
> > On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell  
> > >> wrote:
> >
> >
> >
> > On 16/06/17 23:51, Neetish Pathak wrote:
> > > Thanks Matt, Appreciate ur response and tips
> > >
> > > On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell 
> 
> >
> > > 
>  > >
> > >
> > >
> > > On 16/06/17 20:08, Benjamin Kaduk via openssl-users
> wrote:
> > > > On 06/16/2017 01:58 PM, Neetish Pathak wrote:
> > > >> Hello
> > > >> Thanks
> > > >> I tried reading  some content from the server
> side and I
> > observed the
> > > >> new_session_cb getting invoked in that case on
> the client
> > side. I
> > > >> understand that may be due to delayed NewSession info
> > transfer from
> > > >> server side to client side. But it is helpful for
> saving
> > the session
> > > >> info 

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

I wanted to understand the replay attack vulnerability in case of enable
early data of TLS 1.3 while false start is secure in that respect as I have
read from https://github.com/openssl/openssl/issues/1541
So, with false start, the application data is sent from client after the
first leg of the handshake i.e. one round trip is complete, so the data
goes encrypted even though the handshake is not completed. In enable early
data mode in TLS 1.3 for 0-RTT for session resumption, the application data
is sent from the client along with the client hello message. Does the
application data in early data mode go as clear text ? I assume this is
also encrypted using the PSK because 0-RTT is only applicable when PSK is
available on the client side. How is it vulnerable to replay attack. Please
help me understand.

Is there any API available in OpenSSL for false start ?

Thanks
Best regards,
Neetish

On Tue, Jun 20, 2017 at 11:52 AM, Neetish Pathak  wrote:

> I Appreciate your response
>
> On Tue, Jun 20, 2017 at 2:09 AM, Matt Caswell  wrote:
>
>>
>>
>> On 19/06/17 19:11, Neetish Pathak wrote:
>> > 2) Can you suggest some places to put a time stamp in OpenSSL code.
>>
>> I agree with Ben's responses to all your other questions. For this
>> question, I'm not sure what you are trying to achieve? Starting before
>> SSL_accept/SSL_connect and finishing after they return should be fine.
>> Or are you looking for a breakdown of where the time is going?
>>
>> Thanks Matt. I was asking for a breakdown since I was not sure if the
>> SSL_accept and SSL_connect just do the handshake or if they are doing some
>> other things that may impact latency and CPU usage. Just wanted to be clear
>> that calling SSL_connect  starts ClientHello , SSL_accept unblocks on
>> receiving ClientHello and sends ServerHello, and both functions return
>> after sending Finished message from their sides (i.e. client and server).
>
>
>
>
>
>> Matt
>>
>> >
>> > Thanks
>> > Best Regards,
>> > Neetish
>> >
>> > On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell > > > wrote:
>> >
>> >
>> >
>> > On 16/06/17 23:51, Neetish Pathak wrote:
>> > > Thanks Matt, Appreciate ur response and tips
>> > >
>> > > On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell > 
>> > > >> wrote:
>> > >
>> > >
>> > >
>> > > On 16/06/17 20:08, Benjamin Kaduk via openssl-users wrote:
>> > > > On 06/16/2017 01:58 PM, Neetish Pathak wrote:
>> > > >> Hello
>> > > >> Thanks
>> > > >> I tried reading  some content from the server side and I
>> > observed the
>> > > >> new_session_cb getting invoked in that case on the client
>> > side. I
>> > > >> understand that may be due to delayed NewSession info
>> > transfer from
>> > > >> server side to client side. But it is helpful for saving
>> > the session
>> > > >> info on the client side. (Thanks Matt for your input)
>> > > >>
>> > > >> However, now I have two concerns
>> > > >>
>> > > >> 1) I see that latency for handshake with session
>> resumption in
>> > > TLS 1.3
>> > > >> has not improved as much as it improves for TLS 1.2
>> > > >> With TLS 1.3, I observed that resumption brings down the
>> > connection
>> > > >> time from 2.5 ms to 1.2-1.3 ms
>> > > >> while with TLS 1.2 (using either session IDs or tickets),
>> the
>> > > >> connection time reduces from 2.5 ms to 0.5-0.6 ms.
>> > > >>
>> > > >> The whole code is similar for running the two experiments
>> > with only
>> > > >> max TLS version changed. Can someone comment on the latency
>> > > >> measurements for the two cases.
>> > > >> TLS 1.3 is supposed to be better than TLS 1.2 in my
>> > opinion. Please
>> > > >> comment.
>> > > >>
>> > > >
>> > > > Are you seeing a HelloRetryRequest in the resumption flow?
>> > That would
>> > > > add an additional round trip.  (Your numbers in milliseconds
>> > are of
>> > > > course not transferrable to other systems; round-trips is an
>> > easier to
>> > > > understand number.)  RFC 5246 and draft-ietf-tls-tls13-20
>> > both have
>> > > > message-flow diagrams that show the number of round trips in
>> > various
>> > > > handshake flows.
>> > >
>> > > Care should also be taken about when you are starting your
>> > "timer" and
>> > > when you stop it, e.g. if you stop your timer after the
>> > session ticket
>> > > data has been received by the client then this is not a "fair"
>> > test (the
>> > > connection is ready for data transfer earlier than the arrival
>> > of the
>> > > session 

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

I Appreciate your response

On Tue, Jun 20, 2017 at 2:09 AM, Matt Caswell  wrote:

>
>
> On 19/06/17 19:11, Neetish Pathak wrote:
> > 2) Can you suggest some places to put a time stamp in OpenSSL code.
>
> I agree with Ben's responses to all your other questions. For this
> question, I'm not sure what you are trying to achieve? Starting before
> SSL_accept/SSL_connect and finishing after they return should be fine.
> Or are you looking for a breakdown of where the time is going?
>
> Thanks Matt. I was asking for a breakdown since I was not sure if the
> SSL_accept and SSL_connect just do the handshake or if they are doing some
> other things that may impact latency and CPU usage. Just wanted to be clear
> that calling SSL_connect  starts ClientHello , SSL_accept unblocks on
> receiving ClientHello and sends ServerHello, and both functions return
> after sending Finished message from their sides (i.e. client and server).





> Matt
>
> >
> > Thanks
> > Best Regards,
> > Neetish
> >
> > On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell  > > wrote:
> >
> >
> >
> > On 16/06/17 23:51, Neetish Pathak wrote:
> > > Thanks Matt, Appreciate ur response and tips
> > >
> > > On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell  
> > > >> wrote:
> > >
> > >
> > >
> > > On 16/06/17 20:08, Benjamin Kaduk via openssl-users wrote:
> > > > On 06/16/2017 01:58 PM, Neetish Pathak wrote:
> > > >> Hello
> > > >> Thanks
> > > >> I tried reading  some content from the server side and I
> > observed the
> > > >> new_session_cb getting invoked in that case on the client
> > side. I
> > > >> understand that may be due to delayed NewSession info
> > transfer from
> > > >> server side to client side. But it is helpful for saving
> > the session
> > > >> info on the client side. (Thanks Matt for your input)
> > > >>
> > > >> However, now I have two concerns
> > > >>
> > > >> 1) I see that latency for handshake with session resumption
> in
> > > TLS 1.3
> > > >> has not improved as much as it improves for TLS 1.2
> > > >> With TLS 1.3, I observed that resumption brings down the
> > connection
> > > >> time from 2.5 ms to 1.2-1.3 ms
> > > >> while with TLS 1.2 (using either session IDs or tickets),
> the
> > > >> connection time reduces from 2.5 ms to 0.5-0.6 ms.
> > > >>
> > > >> The whole code is similar for running the two experiments
> > with only
> > > >> max TLS version changed. Can someone comment on the latency
> > > >> measurements for the two cases.
> > > >> TLS 1.3 is supposed to be better than TLS 1.2 in my
> > opinion. Please
> > > >> comment.
> > > >>
> > > >
> > > > Are you seeing a HelloRetryRequest in the resumption flow?
> > That would
> > > > add an additional round trip.  (Your numbers in milliseconds
> > are of
> > > > course not transferrable to other systems; round-trips is an
> > easier to
> > > > understand number.)  RFC 5246 and draft-ietf-tls-tls13-20
> > both have
> > > > message-flow diagrams that show the number of round trips in
> > various
> > > > handshake flows.
> > >
> > > Care should also be taken about when you are starting your
> > "timer" and
> > > when you stop it, e.g. if you stop your timer after the
> > session ticket
> > > data has been received by the client then this is not a "fair"
> > test (the
> > > connection is ready for data transfer earlier than the arrival
> > of the
> > > session ticket).
> > >
> > > I would expect to see the TLS1.3 latency for a full handshake
> > to be
> > > around the same as for a TLS1.2 resumption handshake. With a
> > TLS1.3
> > > resumption only marginally different. There are the same
> > number of round
> > > trips for a TLS1.3 full handshake as that there are for a
> > resumption
> > > one. The primary difference is that the Certificate message is
> > not sent
> > > (which can be quite a large message).
> > >
> > > Your timings suggest you are testing this over a LAN where the
> > effects
> > > of network latency are going to be relatively low. The real
> > benefits
> > > from fewer round trips will really be seen when network
> > latency is more
> > > significant.
> > >
> > >
> > >
> > > In my application program, I put start and stop timer before and
> after
> > > SSL_accept on server side and before and after SSL_connect on the
> > client
> > > side.
> >
> > That 

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

Thanks Ben for all the replies and your comments. They are extremely useful
for my study

On Mon, Jun 19, 2017 at 9:21 PM, Benjamin Kaduk  wrote:

> On 06/19/2017 04:12 PM, Neetish Pathak wrote:
>
>
>
> On Mon, Jun 19, 2017 at 11:11 AM, Neetish Pathak 
> wrote:
>
>> Hi Matt,
>> Thanks
>> Could you help with following queries
>>
>> 1) On the blogpost for TLS1.3, you mentions the following in the session
>> section
>> The specification recommends that applications only use a session once
>> (although this is not enforced). For this reason some servers send multiple
>> session messages to a client. To enforce the “use once” recommendation
>> applications could use SSL_CTX_remove_session() to mark a session as
>> non-resumable (and remove it from the cache) once it has been used.
>>
>> I am a bit confused here as to why "use once" is recommended. How will
>> resumption be ensured then ? I get a PSK in first connection and use it
>> again for all the other connections.
>>
>>
> "use once" is recommended in a limited circumstance, to prevent an
> attacker listening on the network from associating the (multiple) resumed
> sessions as being derived from the initial session.
> This is a new possibility in TLS 1.3, since in TLS 1.2 the session ticket
> was given to the client in cleartext (and presented back to the server in
> cleartext), so all uses of the ticket were traceable back to the original
> connection and linkable to each other.
>
> Using a given ticket more than once in TLS 1.3 just brings things back to
> basically the TLS 1.2 state in terms of linkability; it's not a
> catastrophic failure or anything like that.
>
>
>> On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell  wrote:
>>
>>>
>>>
> Yes Matt, when I switch to remote machines and test my application
> programs, I see that TLS 1.3 is faster than TLS 1.2 in the first connection
> (around same time as resumption time in TLS 1.2) itself and there is
> marginal or no improvement in the subsequent connections even on using
> resumption. Does this mean that resumption in TLS 1.3 is bringing not much
> benefit in terms of latency. It makes sense because round trips count for
> resumption or no resumption is 1 in TLS 1.3.
>
> The only benefit with resumption is that the client can now send zero-RTT
> data. (early data). However, if we consider the overall latency in
> handshake, it is going to be the same equivalent to 1 round trip.
> Is my understanding correct ?
>
> Is there any way to enable early data or it gets activated by default once
> the pre-shared keys are available at both the client and server ends ?
>
>
> No no no no no, many times no.
> You really must not blindly enable early data without a proper protocol
> analysis to determine what would happen if an attacker replayed the early
> data millions of times, as is possible with the current TLS 1.3 draft
> specification.  There are a lot of ways to hurt yourself and your users
> with it, and I strongly recommend against trying to enable it just because
> it looks faster.
> (There are separate APIs from the normal read/write APIs to use early
> data, to make you explicitly think about whether it's safe when adding
> support to an application.)
>
>
>
The comments give me much food for thought. I am still wondering on  on the
possibility for replay attacks when early data is enabled. Sorry, I am new
to OpenSSL or TLS and have so many doubts. So, I understood replay attacks
are possible as in early data enabled mode, data will go in the cleartext
form along with clientHello, so a middleman can look into the data and
replay it later. I was thinking if we use some kind of sequence number/
timestamps (as possible solution) to avoid this or it has been implemented
in OpenSSL ?
I am using the application for an internal project which is not going to be
public. So, I am wondering if it can be used. Nevertheless, your
recommendation is duly noted.


> I believe session resumption as a concept doesn't hold that much value
> from TLS 1.3 onwards since 1-RTT is directly achieved in TLS 1.3 first
> connection. Do you agree?
>
>
> No.  Resumption saves on transferring (and validating!) certificates and
> can be done without incurring the cost of an additional diffie-hellman
> exchange, among other things.
>
> -Ben
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Matt Caswell]

On 19/06/17 19:11, Neetish Pathak wrote:
> 2) Can you suggest some places to put a time stamp in OpenSSL code. 

I agree with Ben's responses to all your other questions. For this
question, I'm not sure what you are trying to achieve? Starting before
SSL_accept/SSL_connect and finishing after they return should be fine.
Or are you looking for a breakdown of where the time is going?


Matt

> 
> Thanks
> Best Regards,
> Neetish
> 
> On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell  > wrote:
> 
> 
> 
> On 16/06/17 23:51, Neetish Pathak wrote:
> > Thanks Matt, Appreciate ur response and tips
> >
> > On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell  
> > >> wrote:
> >
> >
> >
> > On 16/06/17 20:08, Benjamin Kaduk via openssl-users wrote:
> > > On 06/16/2017 01:58 PM, Neetish Pathak wrote:
> > >> Hello
> > >> Thanks
> > >> I tried reading  some content from the server side and I
> observed the
> > >> new_session_cb getting invoked in that case on the client
> side. I
> > >> understand that may be due to delayed NewSession info
> transfer from
> > >> server side to client side. But it is helpful for saving
> the session
> > >> info on the client side. (Thanks Matt for your input)
> > >>
> > >> However, now I have two concerns
> > >>
> > >> 1) I see that latency for handshake with session resumption in
> > TLS 1.3
> > >> has not improved as much as it improves for TLS 1.2
> > >> With TLS 1.3, I observed that resumption brings down the
> connection
> > >> time from 2.5 ms to 1.2-1.3 ms
> > >> while with TLS 1.2 (using either session IDs or tickets), the
> > >> connection time reduces from 2.5 ms to 0.5-0.6 ms.
> > >>
> > >> The whole code is similar for running the two experiments
> with only
> > >> max TLS version changed. Can someone comment on the latency
> > >> measurements for the two cases.
> > >> TLS 1.3 is supposed to be better than TLS 1.2 in my
> opinion. Please
> > >> comment.
> > >>
> > >
> > > Are you seeing a HelloRetryRequest in the resumption flow? 
> That would
> > > add an additional round trip.  (Your numbers in milliseconds
> are of
> > > course not transferrable to other systems; round-trips is an
> easier to
> > > understand number.)  RFC 5246 and draft-ietf-tls-tls13-20
> both have
> > > message-flow diagrams that show the number of round trips in
> various
> > > handshake flows.
> >
> > Care should also be taken about when you are starting your
> "timer" and
> > when you stop it, e.g. if you stop your timer after the
> session ticket
> > data has been received by the client then this is not a "fair"
> test (the
> > connection is ready for data transfer earlier than the arrival
> of the
> > session ticket).
> >
> > I would expect to see the TLS1.3 latency for a full handshake
> to be
> > around the same as for a TLS1.2 resumption handshake. With a
> TLS1.3
> > resumption only marginally different. There are the same
> number of round
> > trips for a TLS1.3 full handshake as that there are for a
> resumption
> > one. The primary difference is that the Certificate message is
> not sent
> > (which can be quite a large message).
> >
> > Your timings suggest you are testing this over a LAN where the
> effects
> > of network latency are going to be relatively low. The real
> benefits
> > from fewer round trips will really be seen when network
> latency is more
> > significant.
> >
> >
> >
> > In my application program, I put start and stop timer before and after
> > SSL_accept on server side and before and after SSL_connect on the
> client
> > side.
> 
> That should be fine (my worry was that you might also be including the
> subsequent session ticket transfer).
> 
> > I am not sure how I can put timers at individual steps of Handshake
> > using my client applications. I was assuming SSL and SSL_accept take
> > care of the entire handshake process.
> >
> > Yes, I am testing on local machine. I will migrate my test to remote
> > machines. But I am not really able to understand why TLS 1.3 is slower
> > on my machine.
> 
> If you are on a local machine I would not expect a significant speed up
> in TLSv1.3 vs TLSv1.2. TLSv1.3 has been designed to reduce the number of
> round-trips required in order to avoid unnecessary network latency. If
> you are on a local machine then 

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Benjamin Kaduk via openssl-users]

On 06/19/2017 04:12 PM, Neetish Pathak wrote:
>
>
> On Mon, Jun 19, 2017 at 11:11 AM, Neetish Pathak  > wrote:
>
> Hi Matt,
> Thanks
> Could you help with following queries
>
> 1) On the blogpost for TLS1.3, you mentions the following in the
> session section
> The specification recommends that applications only use a session
> once (although this is not enforced). For this reason some servers
> send multiple session messages to a client. To enforce the “use
> once” recommendation applications could
> use |SSL_CTX_remove_session()| to mark a session as non-resumable
> (and remove it from the cache) once it has been used.
>
> I am a bit confused here as to why "use once" is recommended. How
> will resumption be ensured then ? I get a PSK in first connection
> and use it again for all the other connections.
>

"use once" is recommended in a limited circumstance, to prevent an
attacker listening on the network from associating the (multiple)
resumed sessions as being derived from the initial session.
This is a new possibility in TLS 1.3, since in TLS 1.2 the session
ticket was given to the client in cleartext (and presented back to the
server in cleartext), so all uses of the ticket were traceable back to
the original connection and linkable to each other.

Using a given ticket more than once in TLS 1.3 just brings things back
to basically the TLS 1.2 state in terms of linkability; it's not a
catastrophic failure or anything like that.

>
> On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell  > wrote:
>
>
>
> Yes Matt, when I switch to remote machines and test my application
> programs, I see that TLS 1.3 is faster than TLS 1.2 in the first
> connection (around same time as resumption time in TLS 1.2) itself and
> there is marginal or no improvement in the subsequent connections even
> on using resumption. Does this mean that resumption in TLS 1.3 is
> bringing not much benefit in terms of latency. It makes sense because
> round trips count for resumption or no resumption is 1 in TLS 1.3. 
>
> The only benefit with resumption is that the client can now send
> zero-RTT data. (early data). However, if we consider the overall
> latency in handshake, it is going to be the same equivalent to 1 round
> trip.
> Is my understanding correct ?
>
> Is there any way to enable early data or it gets activated by default
> once the pre-shared keys are available at both the client and server
> ends ?
>

No no no no no, many times no.
You really must not blindly enable early data without a proper protocol
analysis to determine what would happen if an attacker replayed the
early data millions of times, as is possible with the current TLS 1.3
draft specification.  There are a lot of ways to hurt yourself and your
users with it, and I strongly recommend against trying to enable it just
because it looks faster.
(There are separate APIs from the normal read/write APIs to use early
data, to make you explicitly think about whether it's safe when adding
support to an application.)


> I believe session resumption as a concept doesn't hold that much value
> from TLS 1.3 onwards since 1-RTT is directly achieved in TLS 1.3 first
> connection. Do you agree?
>

No.  Resumption saves on transferring (and validating!) certificates and
can be done without incurring the cost of an additional diffie-hellman
exchange, among other things.

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

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

On Mon, Jun 19, 2017 at 11:11 AM, Neetish Pathak  wrote:

> Hi Matt,
> Thanks
> Could you help with following queries
>
> 1) On the blogpost for TLS1.3, you mentions the following in the session
> section
> The specification recommends that applications only use a session once
> (although this is not enforced). For this reason some servers send multiple
> session messages to a client. To enforce the “use once” recommendation
> applications could use SSL_CTX_remove_session() to mark a session as
> non-resumable (and remove it from the cache) once it has been used.
>
> I am a bit confused here as to why "use once" is recommended. How will
> resumption be ensured then ? I get a PSK in first connection and use it
> again for all the other connections.
>
>
> 2) Can you suggest some places to put a time stamp in OpenSSL code.
>
> Thanks
> Best Regards,
> Neetish
>
> On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell  wrote:
>
>>
>>
>> On 16/06/17 23:51, Neetish Pathak wrote:
>> > Thanks Matt, Appreciate ur response and tips
>> >
>> > On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell > > > wrote:
>> >
>> >
>> >
>> > On 16/06/17 20:08, Benjamin Kaduk via openssl-users wrote:
>> > > On 06/16/2017 01:58 PM, Neetish Pathak wrote:
>> > >> Hello
>> > >> Thanks
>> > >> I tried reading  some content from the server side and I
>> observed the
>> > >> new_session_cb getting invoked in that case on the client side. I
>> > >> understand that may be due to delayed NewSession info transfer
>> from
>> > >> server side to client side. But it is helpful for saving the
>> session
>> > >> info on the client side. (Thanks Matt for your input)
>> > >>
>> > >> However, now I have two concerns
>> > >>
>> > >> 1) I see that latency for handshake with session resumption in
>> > TLS 1.3
>> > >> has not improved as much as it improves for TLS 1.2
>> > >> With TLS 1.3, I observed that resumption brings down the
>> connection
>> > >> time from 2.5 ms to 1.2-1.3 ms
>> > >> while with TLS 1.2 (using either session IDs or tickets), the
>> > >> connection time reduces from 2.5 ms to 0.5-0.6 ms.
>> > >>
>> > >> The whole code is similar for running the two experiments with
>> only
>> > >> max TLS version changed. Can someone comment on the latency
>> > >> measurements for the two cases.
>> > >> TLS 1.3 is supposed to be better than TLS 1.2 in my opinion.
>> Please
>> > >> comment.
>> > >>
>> > >
>> > > Are you seeing a HelloRetryRequest in the resumption flow?  That
>> would
>> > > add an additional round trip.  (Your numbers in milliseconds are
>> of
>> > > course not transferrable to other systems; round-trips is an
>> easier to
>> > > understand number.)  RFC 5246 and draft-ietf-tls-tls13-20 both
>> have
>> > > message-flow diagrams that show the number of round trips in
>> various
>> > > handshake flows.
>> >
>> > Care should also be taken about when you are starting your "timer"
>> and
>> > when you stop it, e.g. if you stop your timer after the session
>> ticket
>> > data has been received by the client then this is not a "fair" test
>> (the
>> > connection is ready for data transfer earlier than the arrival of
>> the
>> > session ticket).
>> >
>> > I would expect to see the TLS1.3 latency for a full handshake to be
>> > around the same as for a TLS1.2 resumption handshake. With a TLS1.3
>> > resumption only marginally different. There are the same number of
>> round
>> > trips for a TLS1.3 full handshake as that there are for a resumption
>> > one. The primary difference is that the Certificate message is not
>> sent
>> > (which can be quite a large message).
>>
>

Yes Matt, when I switch to remote machines and test my application
programs, I see that TLS 1.3 is faster than TLS 1.2 in the first connection
(around same time as resumption time in TLS 1.2) itself and there is
marginal or no improvement in the subsequent connections even on using
resumption. Does this mean that resumption in TLS 1.3 is bringing not much
benefit in terms of latency. It makes sense because round trips count for
resumption or no resumption is 1 in TLS 1.3.

The only benefit with resumption is that the client can now send zero-RTT
data. (early data). However, if we consider the overall latency in
handshake, it is going to be the same equivalent to 1 round trip.
Is my understanding correct ?

Is there any way to enable early data or it gets activated by default once
the pre-shared keys are available at both the client and server ends ?

I believe session resumption as a concept doesn't hold that much value from
TLS 1.3 onwards since 1-RTT is directly achieved in TLS 1.3 first
connection. Do you agree?


> >
>> > Your timings suggest you are testing this over a LAN where the
>> effects
>> > of network latency are 

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

Hi Matt,
Thanks
Could you help with following queries

1) On the blogpost for TLS1.3, you mentions the following in the session
section
The specification recommends that applications only use a session once
(although this is not enforced). For this reason some servers send multiple
session messages to a client. To enforce the “use once” recommendation
applications could use SSL_CTX_remove_session() to mark a session as
non-resumable (and remove it from the cache) once it has been used.

I am a bit confused here as to why "use once" is recommended. How will
resumption be ensured then ? I get a PSK in first connection and use it
again for all the other connections.


2) Can you suggest some places to put a time stamp in OpenSSL code.

Thanks
Best Regards,
Neetish

On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell  wrote:

>
>
> On 16/06/17 23:51, Neetish Pathak wrote:
> > Thanks Matt, Appreciate ur response and tips
> >
> > On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell  > > wrote:
> >
> >
> >
> > On 16/06/17 20:08, Benjamin Kaduk via openssl-users wrote:
> > > On 06/16/2017 01:58 PM, Neetish Pathak wrote:
> > >> Hello
> > >> Thanks
> > >> I tried reading  some content from the server side and I observed
> the
> > >> new_session_cb getting invoked in that case on the client side. I
> > >> understand that may be due to delayed NewSession info transfer
> from
> > >> server side to client side. But it is helpful for saving the
> session
> > >> info on the client side. (Thanks Matt for your input)
> > >>
> > >> However, now I have two concerns
> > >>
> > >> 1) I see that latency for handshake with session resumption in
> > TLS 1.3
> > >> has not improved as much as it improves for TLS 1.2
> > >> With TLS 1.3, I observed that resumption brings down the
> connection
> > >> time from 2.5 ms to 1.2-1.3 ms
> > >> while with TLS 1.2 (using either session IDs or tickets), the
> > >> connection time reduces from 2.5 ms to 0.5-0.6 ms.
> > >>
> > >> The whole code is similar for running the two experiments with
> only
> > >> max TLS version changed. Can someone comment on the latency
> > >> measurements for the two cases.
> > >> TLS 1.3 is supposed to be better than TLS 1.2 in my opinion.
> Please
> > >> comment.
> > >>
> > >
> > > Are you seeing a HelloRetryRequest in the resumption flow?  That
> would
> > > add an additional round trip.  (Your numbers in milliseconds are of
> > > course not transferrable to other systems; round-trips is an
> easier to
> > > understand number.)  RFC 5246 and draft-ietf-tls-tls13-20 both have
> > > message-flow diagrams that show the number of round trips in
> various
> > > handshake flows.
> >
> > Care should also be taken about when you are starting your "timer"
> and
> > when you stop it, e.g. if you stop your timer after the session
> ticket
> > data has been received by the client then this is not a "fair" test
> (the
> > connection is ready for data transfer earlier than the arrival of the
> > session ticket).
> >
> > I would expect to see the TLS1.3 latency for a full handshake to be
> > around the same as for a TLS1.2 resumption handshake. With a TLS1.3
> > resumption only marginally different. There are the same number of
> round
> > trips for a TLS1.3 full handshake as that there are for a resumption
> > one. The primary difference is that the Certificate message is not
> sent
> > (which can be quite a large message).
> >
> > Your timings suggest you are testing this over a LAN where the
> effects
> > of network latency are going to be relatively low. The real benefits
> > from fewer round trips will really be seen when network latency is
> more
> > significant.
> >
> >
> >
> > In my application program, I put start and stop timer before and after
> > SSL_accept on server side and before and after SSL_connect on the client
> > side.
>
> That should be fine (my worry was that you might also be including the
> subsequent session ticket transfer).
>
> > I am not sure how I can put timers at individual steps of Handshake
> > using my client applications. I was assuming SSL and SSL_accept take
> > care of the entire handshake process.
> >
> > Yes, I am testing on local machine. I will migrate my test to remote
> > machines. But I am not really able to understand why TLS 1.3 is slower
> > on my machine.
>
> If you are on a local machine I would not expect a significant speed up
> in TLSv1.3 vs TLSv1.2. TLSv1.3 has been designed to reduce the number of
> round-trips required in order to avoid unnecessary network latency. If
> you are on a local machine then there isn't any significant network
> latency anyway - so timings are presumably dominated by the CPU
> intensive tasks. You should make sure that you are comparing like with
> like, 

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Matt Caswell]

On 16/06/17 23:51, Neetish Pathak wrote:
> Thanks Matt, Appreciate ur response and tips
> 
> On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell  > wrote:
> 
> 
> 
> On 16/06/17 20:08, Benjamin Kaduk via openssl-users wrote:
> > On 06/16/2017 01:58 PM, Neetish Pathak wrote:
> >> Hello
> >> Thanks
> >> I tried reading  some content from the server side and I observed the
> >> new_session_cb getting invoked in that case on the client side. I
> >> understand that may be due to delayed NewSession info transfer from
> >> server side to client side. But it is helpful for saving the session
> >> info on the client side. (Thanks Matt for your input)
> >>
> >> However, now I have two concerns
> >>
> >> 1) I see that latency for handshake with session resumption in
> TLS 1.3
> >> has not improved as much as it improves for TLS 1.2
> >> With TLS 1.3, I observed that resumption brings down the connection
> >> time from 2.5 ms to 1.2-1.3 ms
> >> while with TLS 1.2 (using either session IDs or tickets), the
> >> connection time reduces from 2.5 ms to 0.5-0.6 ms.
> >>
> >> The whole code is similar for running the two experiments with only
> >> max TLS version changed. Can someone comment on the latency
> >> measurements for the two cases.
> >> TLS 1.3 is supposed to be better than TLS 1.2 in my opinion. Please
> >> comment.
> >>
> >
> > Are you seeing a HelloRetryRequest in the resumption flow?  That would
> > add an additional round trip.  (Your numbers in milliseconds are of
> > course not transferrable to other systems; round-trips is an easier to
> > understand number.)  RFC 5246 and draft-ietf-tls-tls13-20 both have
> > message-flow diagrams that show the number of round trips in various
> > handshake flows.
> 
> Care should also be taken about when you are starting your "timer" and
> when you stop it, e.g. if you stop your timer after the session ticket
> data has been received by the client then this is not a "fair" test (the
> connection is ready for data transfer earlier than the arrival of the
> session ticket).
> 
> I would expect to see the TLS1.3 latency for a full handshake to be
> around the same as for a TLS1.2 resumption handshake. With a TLS1.3
> resumption only marginally different. There are the same number of round
> trips for a TLS1.3 full handshake as that there are for a resumption
> one. The primary difference is that the Certificate message is not sent
> (which can be quite a large message).
> 
> Your timings suggest you are testing this over a LAN where the effects
> of network latency are going to be relatively low. The real benefits
> from fewer round trips will really be seen when network latency is more
> significant.
> 
> 
> 
> In my application program, I put start and stop timer before and after
> SSL_accept on server side and before and after SSL_connect on the client
> side.

That should be fine (my worry was that you might also be including the
subsequent session ticket transfer).

> I am not sure how I can put timers at individual steps of Handshake
> using my client applications. I was assuming SSL and SSL_accept take
> care of the entire handshake process.
> 
> Yes, I am testing on local machine. I will migrate my test to remote
> machines. But I am not really able to understand why TLS 1.3 is slower
> on my machine.

If you are on a local machine I would not expect a significant speed up
in TLSv1.3 vs TLSv1.2. TLSv1.3 has been designed to reduce the number of
round-trips required in order to avoid unnecessary network latency. If
you are on a local machine then there isn't any significant network
latency anyway - so timings are presumably dominated by the CPU
intensive tasks. You should make sure that you are comparing like with
like, i.e. the same ciphers, key lengths, key exchange algorithms,
curves etc between TLSv1.2 and TLSv1.3. Differences in any one of these
could obviously have significant performance impacts.

Matt

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

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

Benjamin/Matt,
Appreciate your tips and help so far.
Could you give me any pointers for placing my timestamps within the OpenSSl
code for right measurement for handshake. I am reading through the master
code. I think since in TLS 1.3 is session tickets are sent after handshake,
it would be ok to place a timestamp in the
*ossl_statem_server_pre_work *function
before *tls_finish_handshake* is called (This function is in state_srvr.c
which updates the stjatemachine I think). *It is only called for TLS 1.3*
*But I do not see any significant change when I put a timestamp here or at
the end of SSL_accept on my server application program.*
*Any help for the right location of time stamps will be appreciated.*

  *case* *TLS_ST_SW_SESSION_TICKET*:

*if* (SSL_IS_TLS13(s)) {

/*

 * Actually this is the end of the handshake, but we're going

 * straight into writing the session ticket out. So we finish
off

 * the handshake, but keep the various buffers active.

 */


/***End time
stamp*/

*struct* timespec end;

*clock_gettime*(CLOCK_MONOTONIC_RAW, );

uint64_t tempTimeEnd = end.tv_nsec / 1000;

*printf*("Handshake End time : %llu \n", tempTimeEnd);


*return* tls_finish_handshake(s, wst, 0);

} *if* (SSL_IS_DTLS(s)) {

/*

 * We're into the last flight. We don't retransmit the last
flight

 * unless we need to, so we don't use the timer

 */

st->use_timer = 0;

}


Thanks

BR,

Neetish

On Fri, Jun 16, 2017 at 5:54 PM, Benjamin Kaduk via openssl-users <
openssl-users@openssl.org> wrote:

> On 06/16/2017 05:36 PM, Matt Caswell wrote:
>
> The security properties of such "external" PSKs are substantially
> different than the "ephemeral" PSKs used in resumption flows.
>
> Ben - Even external PSKs incorporate an ephemeral, per connection, ECDHE
> based secret (assuming a suitable kex_mode is used). What do you see as
> the concern?
>
>
> The risk of accidentally using psk_ke instead of psk_dhe_ke is noticeable,
> and in terms of concrete differences, there are additional requirements on
> external PSKs that the KDF and PSK identity must remain fixed across uses.
> That, combined with the potential for insufficient entropy during key
> generation (mentioned in section 2.2 of draft-20) seem to provide more
> openings for cryptographic attacks than for the full resumption flow.  It
> is probably fine for uses where the other properties of external PSKs are
> needed, but I'm not sure that the risk/reward balance favors using it just
> to get a speedup -- TLS 1.3 resumption should already be pretty fast.
>
> -Ben
>
> --
> 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

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Benjamin Kaduk via openssl-users]

On 06/16/2017 05:36 PM, Matt Caswell wrote:
>> The security properties of such "external" PSKs are substantially
>> different than the "ephemeral" PSKs used in resumption flows.
> Ben - Even external PSKs incorporate an ephemeral, per connection, ECDHE
> based secret (assuming a suitable kex_mode is used). What do you see as
> the concern?

The risk of accidentally using psk_ke instead of psk_dhe_ke is
noticeable, and in terms of concrete differences, there are additional
requirements on external PSKs that the KDF and PSK identity must remain
fixed across uses.  That, combined with the potential for insufficient
entropy during key generation (mentioned in section 2.2 of draft-20)
seem to provide more openings for cryptographic attacks than for the
full resumption flow.  It is probably fine for uses where the other
properties of external PSKs are needed, but I'm not sure that the
risk/reward balance favors using it just to get a speedup -- TLS 1.3
resumption should already be pretty fast.

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

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

Thanks Matt, Appreciate ur response and tips

On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell  wrote:

>
>
> On 16/06/17 20:08, Benjamin Kaduk via openssl-users wrote:
> > On 06/16/2017 01:58 PM, Neetish Pathak wrote:
> >> Hello
> >> Thanks
> >> I tried reading  some content from the server side and I observed the
> >> new_session_cb getting invoked in that case on the client side. I
> >> understand that may be due to delayed NewSession info transfer from
> >> server side to client side. But it is helpful for saving the session
> >> info on the client side. (Thanks Matt for your input)
> >>
> >> However, now I have two concerns
> >>
> >> 1) I see that latency for handshake with session resumption in TLS 1.3
> >> has not improved as much as it improves for TLS 1.2
> >> With TLS 1.3, I observed that resumption brings down the connection
> >> time from 2.5 ms to 1.2-1.3 ms
> >> while with TLS 1.2 (using either session IDs or tickets), the
> >> connection time reduces from 2.5 ms to 0.5-0.6 ms.
> >>
> >> The whole code is similar for running the two experiments with only
> >> max TLS version changed. Can someone comment on the latency
> >> measurements for the two cases.
> >> TLS 1.3 is supposed to be better than TLS 1.2 in my opinion. Please
> >> comment.
> >>
> >
> > Are you seeing a HelloRetryRequest in the resumption flow?  That would
> > add an additional round trip.  (Your numbers in milliseconds are of
> > course not transferrable to other systems; round-trips is an easier to
> > understand number.)  RFC 5246 and draft-ietf-tls-tls13-20 both have
> > message-flow diagrams that show the number of round trips in various
> > handshake flows.
>
> Care should also be taken about when you are starting your "timer" and
> when you stop it, e.g. if you stop your timer after the session ticket
> data has been received by the client then this is not a "fair" test (the
> connection is ready for data transfer earlier than the arrival of the
> session ticket).
>
> I would expect to see the TLS1.3 latency for a full handshake to be
> around the same as for a TLS1.2 resumption handshake. With a TLS1.3
> resumption only marginally different. There are the same number of round
> trips for a TLS1.3 full handshake as that there are for a resumption
> one. The primary difference is that the Certificate message is not sent
> (which can be quite a large message).
>
> Your timings suggest you are testing this over a LAN where the effects
> of network latency are going to be relatively low. The real benefits
> from fewer round trips will really be seen when network latency is more
> significant.
>


In my application program, I put start and stop timer before and after
SSL_accept on server side and before and after SSL_connect on the client
side.
I am not sure how I can put timers at individual steps of Handshake using
my client applications. I was assuming SSL and SSL_accept take care of the
entire handshake process.

Yes, I am testing on local machine. I will migrate my test to remote
machines. But I am not really able to understand why TLS 1.3 is slower on
my machine.

Also, it is difficult to see all the messages for TLS 1.3 since all
messages after server hello are encrypted when I see on Wireshark. So I am
not sure where exactly session ticket info is exchanged

>
> >
> >> 2) PSK (Pre-shared keys) for resumption are highly emphasized in TLS
> >> 1.3 RFC. How do we generate pre-shared keys in advance even without
> >> making the first connection. Can someone guide me in the right
> direction.
>
> As Ben says this is not currently supported in master but there is
> pending WIP PR to add it.
>
> >>
> >
> > The security properties of such "external" PSKs are substantially
> > different than the "ephemeral" PSKs used in resumption flows.
>
> Ben - Even external PSKs incorporate an ephemeral, per connection, ECDHE
> based secret (assuming a suitable kex_mode is used). What do you see as
> the concern?
>
> 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

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Matt Caswell]

On 16/06/17 20:08, Benjamin Kaduk via openssl-users wrote:
> On 06/16/2017 01:58 PM, Neetish Pathak wrote:
>> Hello 
>> Thanks
>> I tried reading  some content from the server side and I observed the
>> new_session_cb getting invoked in that case on the client side. I
>> understand that may be due to delayed NewSession info transfer from
>> server side to client side. But it is helpful for saving the session
>> info on the client side. (Thanks Matt for your input)
>>
>> However, now I have two concerns
>>
>> 1) I see that latency for handshake with session resumption in TLS 1.3
>> has not improved as much as it improves for TLS 1.2
>> With TLS 1.3, I observed that resumption brings down the connection
>> time from 2.5 ms to 1.2-1.3 ms
>> while with TLS 1.2 (using either session IDs or tickets), the
>> connection time reduces from 2.5 ms to 0.5-0.6 ms.
>>
>> The whole code is similar for running the two experiments with only
>> max TLS version changed. Can someone comment on the latency
>> measurements for the two cases.
>> TLS 1.3 is supposed to be better than TLS 1.2 in my opinion. Please
>> comment.
>>
> 
> Are you seeing a HelloRetryRequest in the resumption flow?  That would
> add an additional round trip.  (Your numbers in milliseconds are of
> course not transferrable to other systems; round-trips is an easier to
> understand number.)  RFC 5246 and draft-ietf-tls-tls13-20 both have
> message-flow diagrams that show the number of round trips in various
> handshake flows.

Care should also be taken about when you are starting your "timer" and
when you stop it, e.g. if you stop your timer after the session ticket
data has been received by the client then this is not a "fair" test (the
connection is ready for data transfer earlier than the arrival of the
session ticket).

I would expect to see the TLS1.3 latency for a full handshake to be
around the same as for a TLS1.2 resumption handshake. With a TLS1.3
resumption only marginally different. There are the same number of round
trips for a TLS1.3 full handshake as that there are for a resumption
one. The primary difference is that the Certificate message is not sent
(which can be quite a large message).

Your timings suggest you are testing this over a LAN where the effects
of network latency are going to be relatively low. The real benefits
from fewer round trips will really be seen when network latency is more
significant.

> 
>> 2) PSK (Pre-shared keys) for resumption are highly emphasized in TLS
>> 1.3 RFC. How do we generate pre-shared keys in advance even without
>> making the first connection. Can someone guide me in the right direction.

As Ben says this is not currently supported in master but there is
pending WIP PR to add it.

>>
> 
> The security properties of such "external" PSKs are substantially
> different than the "ephemeral" PSKs used in resumption flows.

Ben - Even external PSKs incorporate an ephemeral, per connection, ECDHE
based secret (assuming a suitable kex_mode is used). What do you see as
the concern?

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

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Benjamin Kaduk via openssl-users]

On 06/16/2017 01:58 PM, Neetish Pathak wrote:
> Hello 
> Thanks
> I tried reading  some content from the server side and I observed the
> new_session_cb getting invoked in that case on the client side. I
> understand that may be due to delayed NewSession info transfer from
> server side to client side. But it is helpful for saving the session
> info on the client side. (Thanks Matt for your input)
>
> However, now I have two concerns
>
> 1) I see that latency for handshake with session resumption in TLS 1.3
> has not improved as much as it improves for TLS 1.2
> With TLS 1.3, I observed that resumption brings down the connection
> time from 2.5 ms to 1.2-1.3 ms
> while with TLS 1.2 (using either session IDs or tickets), the
> connection time reduces from 2.5 ms to 0.5-0.6 ms.
>
> The whole code is similar for running the two experiments with only
> max TLS version changed. Can someone comment on the latency
> measurements for the two cases.
> TLS 1.3 is supposed to be better than TLS 1.2 in my opinion. Please
> comment.
>

Are you seeing a HelloRetryRequest in the resumption flow?  That would
add an additional round trip.  (Your numbers in milliseconds are of
course not transferrable to other systems; round-trips is an easier to
understand number.)  RFC 5246 and draft-ietf-tls-tls13-20 both have
message-flow diagrams that show the number of round trips in various
handshake flows.

> 2) PSK (Pre-shared keys) for resumption are highly emphasized in TLS
> 1.3 RFC. How do we generate pre-shared keys in advance even without
> making the first connection. Can someone guide me in the right direction.
>

The security properties of such "external" PSKs are substantially
different than the "ephemeral" PSKs used in resumption flows.  I do not
think I can recommend their use in the general case when resumption
flows are available.
Regardless, external PSK support is still a work in progress:
https://github.com/openssl/openssl/pull/3670

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

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

Hello
Thanks
I tried reading  some content from the server side and I observed the
new_session_cb getting invoked in that case on the client side. I
understand that may be due to delayed NewSession info transfer from server
side to client side. But it is helpful for saving the session info on the
client side. (Thanks Matt for your input)

However, now I have two concerns

1) I see that latency for handshake with session resumption in TLS 1.3 has
not improved as much as it improves for TLS 1.2
With TLS 1.3, I observed that resumption brings down the connection time
from 2.5 ms to 1.2-1.3 ms
while with TLS 1.2 (using either session IDs or tickets), the connection
time reduces from 2.5 ms to 0.5-0.6 ms.

The whole code is similar for running the two experiments with only max TLS
version changed. Can someone comment on the latency measurements for the
two cases.
TLS 1.3 is supposed to be better than TLS 1.2 in my opinion. Please comment.

2) PSK (Pre-shared keys) for resumption are highly emphasized in TLS 1.3
RFC. How do we generate pre-shared keys in advance even without making the
first connection. Can someone guide me in the right direction.

Thanks
Best Regards,
Neetish

On Thu, Jun 15, 2017 at 2:30 AM, Matt Caswell  wrote:

>
>
> On 14/06/17 18:36, Neetish Pathak wrote:
> >
> > My calling sequence is :
> >
> > client.connectToServer();
> >
> > client.sslTcpConnect();
> >
> > client.sslTcpClosure();
>
> Does your client at any point attempt to read application data (i.e.
> through a call to SSL_read()/SSL_read_ex()?). It is not sufficient to
> just connect to a server via SSL_connect(). Because the session
> information is established *post* handshake in TLSv1.3, OpenSSL won't
> see it unless you actually try and read information from the connection.
>
> 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

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Matt Caswell]

On 14/06/17 18:36, Neetish Pathak wrote:
> 
> My calling sequence is :
> 
> client.connectToServer();
> 
> client.sslTcpConnect();
> 
> client.sslTcpClosure();

Does your client at any point attempt to read application data (i.e.
through a call to SSL_read()/SSL_read_ex()?). It is not sufficient to
just connect to a server via SSL_connect(). Because the session
information is established *post* handshake in TLSv1.3, OpenSSL won't
see it unless you actually try and read information from the connection.

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

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Floodeenjr, Thomas]

Is there a recommendation for a newer book?

-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Salz, Rich via openssl-users
Sent: Wednesday, June 14, 2017 11:43 AM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

> I am quoting a line from Network Security with OpenSSL book (O'Reilly Media)

That book is 15 years old.  Throw it out.
-- 
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

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Salz, Rich via openssl-users]

> Is there a recommendation for a newer book?

Many people like the Feisty Duck book(s).  See if others on this list say 
anything.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Salz, Rich via openssl-users]

> I am quoting a line from Network Security with OpenSSL book (O'Reilly Media)

That book is 15 years old.  Throw it out.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

On Wed, Jun 14, 2017 at 3:43 AM, Matt Caswell  wrote:

>
>
> On 14/06/17 01:38, Salz, Rich via openssl-users wrote:
> > It’s disabled by default.  Servers that want to use server-side session
> > caching have to call an API to turn it on
>
> Err, no, that's not correct. Server side caching is on by default.
> Client side caching is off by default.
>


I am quoting a line from Network Security with OpenSSL book (O'Reilly Media)

"All sessions must have a session ID context. For the server, session
caching is disabled by default unless a call to SSL_CTX_set_session_id_context
is made."

That's why I thought server side session caching is disabled by default.


>
>
> On 14/06/17 02:03, Neetish Pathak wrote:
> > Thanks for your reply Salz. However, I want to know should the session
> > caching be enabled on server side for TLS 1.3 for session resumption.
>
> It should just work by default for TLSv1.3. You don't need to enable
> anything.
>

Yea it worked for previous TLS versions, so everything was inline. But
since with TLS 1.3, I was not observing the same behavior, that's why my
question was for TLS 1.3.

>
> > Also, I need a clarification on how does resumption work in case of
> > session identifiers if server side caching is not enabled
>
> As noted above server side caching is on by default.
>




>
> On 14/06/17 02:33, Neetish Pathak wrote:
> > I need some suggestions on how I can implement session resumption in TLS
> > 1.3. I have implemented the resumption on the client side using a
> > callback as recommended on the TLS 1.3
> > blog https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/
> >  . Still, the
> > session resumption is not working. I know this because my new_session_cb
> > which I have set using SSL_CTX_sess_set_new_cb is never getting invoked
> > and also I don't see any improvement in connection time.
> >
> > The same implementation when I change the max TLS version to TLS1.2
> > works and session resumption works as desired.
> > I am not sure how I can resolve this.
> >
> > As mentioned on the blog post
> >
> > "In TLSv1.3 sessions are not established until after the main handshake
> > has completed. The server sends a separate post-handshake message to the
> > client containing the session details. Typically this will happen soon
> > after the handshake has completed, but it could be sometime later (or
> > not at all)."
> >
> > I think the server is not informing the session details to client at all
> > in my case and hence the resumption is not working. Can someone please
> > suggest how to resolve this
>
> Just to be clear: you are using OpenSSL on both the server and client
> sides right? If you are using something other than OpenSSL on the server
> then the policy might be different around when the session information
> is sent to the client (i.e. it could happen sometime later, or not at
> all). If you are using OpenSSL on the server then it sends its session
> information immediately after the main handshake has completed, so that
> should not be a problem.
>
> So if I understand you correctly the client is successfully creating a
> TLSv1.3 connection, but the client side new session callback is never
> being invoked? Did you call SSL_CTX_sess_set_new_cb() before or after
> the SSL object itself was created? Are you able to share any code for
> how you have done this?
>



Yes, I am using OpenSSl on both the server and client sides and my
implementation works for TLS 1.2.
Yea you understood correctly, the client is creating a connection but new
session callback is not getting invoked.
I have called SSL_CTX_sess_set_new_cb before SSL object is created



Yea, sure following is a snippet from my client side implementation. I have
highlighted the relevant section for new session callback registration



*static* *int* *new_session_cb*(SSL* ssl, SSL_SESSION * sess){



BIO *stmp = BIO_new_file(SESS_OUT,"w");


*if*(stmp == NULL){

BIO_printf(bio_err,"Error writing session file %s\n",SESS_OUT);

}*else*{

fprintf(stderr,"Session getting set\n");

PEM_write_bio_SSL_SESSION(stmp,sess);

BIO_free(stmp);

resumeInput = TRUE;

}


*return* 0;

}


*int* *SocketClient::connectToServer*(){


/*Initialization

** (1)Register SSL/TLS ciphers and digests

** (2)Load Opessl error Strings*/

init_OpenSSL();


/*Creating a new SSL context object*/

ssl_ctx = SSL_CTX_new(TLS_client_method());

SSL_CTX_set_max_proto_version(ssl_ctx, MAX_TLS_VERSION);

SSL_CTX_set_min_proto_version(ssl_ctx, MIN_TLS_VERSION);


*if*(NULL == ssl_ctx){

fail("SocketClient.cpp : ssl_ctx object creation failed"); perror("");

}*else*{

pass("SocketClient.cpp : ssl Context created successfully");

}



*if(ssl_ctx){*

* SSL_CTX_set_session_cache_mode(ssl_ctx, SSL_SESS_CACHE_CLIENT*

* | SSL_SESS_CACHE_NO_INTERNAL_STORE);*

* SSL_CTX_sess_set_new_cb(ssl_ctx, new_session_cb);*

* }*

*return* 0;

}

int *SocketClient::sslTcpConnect*(){


/*Attaching the 

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Matt Caswell]

On 14/06/17 01:38, Salz, Rich via openssl-users wrote:
> It’s disabled by default.  Servers that want to use server-side session
> caching have to call an API to turn it on

Err, no, that's not correct. Server side caching is on by default.
Client side caching is off by default.


On 14/06/17 02:03, Neetish Pathak wrote:
> Thanks for your reply Salz. However, I want to know should the session
> caching be enabled on server side for TLS 1.3 for session resumption.

It should just work by default for TLSv1.3. You don't need to enable
anything.

> Also, I need a clarification on how does resumption work in case of
> session identifiers if server side caching is not enabled

As noted above server side caching is on by default.

On 14/06/17 02:33, Neetish Pathak wrote:
> I need some suggestions on how I can implement session resumption in TLS
> 1.3. I have implemented the resumption on the client side using a
> callback as recommended on the TLS 1.3
> blog https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/
>  . Still, the
> session resumption is not working. I know this because my new_session_cb
> which I have set using SSL_CTX_sess_set_new_cb is never getting invoked
> and also I don't see any improvement in connection time.
>
> The same implementation when I change the max TLS version to TLS1.2
> works and session resumption works as desired.
> I am not sure how I can resolve this.
>
> As mentioned on the blog post
>
> "In TLSv1.3 sessions are not established until after the main handshake
> has completed. The server sends a separate post-handshake message to the
> client containing the session details. Typically this will happen soon
> after the handshake has completed, but it could be sometime later (or
> not at all)."
>
> I think the server is not informing the session details to client at all
> in my case and hence the resumption is not working. Can someone please
> suggest how to resolve this

Just to be clear: you are using OpenSSL on both the server and client
sides right? If you are using something other than OpenSSL on the server
then the policy might be different around when the session information
is sent to the client (i.e. it could happen sometime later, or not at
all). If you are using OpenSSL on the server then it sends its session
information immediately after the main handshake has completed, so that
should not be a problem.

So if I understand you correctly the client is successfully creating a
TLSv1.3 connection, but the client side new session callback is never
being invoked? Did you call SSL_CTX_sess_set_new_cb() before or after
the SSL object itself was created? Are you able to share any code for
how you have done this?

Matt

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

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

I need some suggestions on how I can implement session resumption in TLS
1.3. I have implemented the resumption on the client side using a callback
as recommended on the TLS 1.3 blog https://www.openssl.org/blog/b
log/2017/05/04/tlsv1.3/ . Still, the session resumption is not working. I
know this because my new_session_cb which I have set using
SSL_CTX_sess_set_new_cb
is never getting invoked and also I don't see any improvement in connection
time.

The same implementation when I change the max TLS version to TLS1.2 works
and session resumption works as desired.
I am not sure how I can resolve this.

As mentioned on the blog post

"In TLSv1.3 sessions are not established until after the main handshake has
completed. The server sends a separate post-handshake message to the client
containing the session details. Typically this will happen soon after the
handshake has completed, but it could be sometime later (or not at all)."

I think the server is not informing the session details to client at all in
my case and hence the resumption is not working. Can someone please suggest
how to resolve this.

Thanks
Best Regards,
Neetish


On Tue, Jun 13, 2017 at 6:03 PM, Neetish Pathak  wrote:

> Thanks for your reply Salz. However, I want to know should the session
> caching be enabled on server side for TLS 1.3 for session resumption.
> Also, I need a clarification on how does resumption work in case of
> session identifiers if server side caching is not enabled
>
> Thanks
> BR,
> Neetish
>
> On Tue, Jun 13, 2017 at 5:38 PM, Salz, Rich via openssl-users <
> openssl-users@openssl.org> wrote:
>
>> It’s disabled by default.  Servers that want to use server-side session
>> caching have to call an API to turn it on
>>
>> --
>> 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

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

Thanks for your reply Salz. However, I want to know should the session
caching be enabled on server side for TLS 1.3 for session resumption.
Also, I need a clarification on how does resumption work in case of session
identifiers if server side caching is not enabled

Thanks
BR,
Neetish

On Tue, Jun 13, 2017 at 5:38 PM, Salz, Rich via openssl-users <
openssl-users@openssl.org> wrote:

> It’s disabled by default.  Servers that want to use server-side session
> caching have to call an API to turn it on
>
> --
> 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

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Salz, Rich via openssl-users]

It’s disabled by default.  Servers that want to use server-side session caching 
have to call an API to turn it on
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

Thanks Salz and Benjamin for your feedback. Indeed my Wireshark version was
unable to decode TLS 1.3. I got an update from the shared link.

I had one doubt about the server side session caching. I read that server
side server caching is disabled by default. Then, how is session resumption
possible using session identifiers because that is is stateful resumption
as I have understood with servers maintaining the session info. Whereas
with session tickets, client maintains the session tickets.
I am getting confused on the session caching concept. Could someone please
clarify.

Also, for TLS 1.3, should the server caching be enabled for session
resumption ?

Thanks
BR,
Neetish

On Sat, Jun 10, 2017 at 7:09 AM, Salz, Rich  wrote:

> > It is quite likely that your version of wireshark does not know how to
> properly decode the TLS 1.3 ServerHello.
>
> Please see  https://www.ietf.org/mail-archive/web/tls/current/
> msg22333.html for information about downloading an early release of
> wireshark.
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Salz, Rich via openssl-users]

> It is quite likely that your version of wireshark does not know how to 
> properly decode the TLS 1.3 ServerHello.

Please see  https://www.ietf.org/mail-archive/web/tls/current/msg22333.html for 
information about downloading an early release of wireshark.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Benjamin Kaduk via openssl-users]

On 06/09/2017 07:54 PM, Neetish Pathak wrote:
>
> On Thu, Jun 8, 2017 at 3:45 PM, Matt Caswell  > wrote:
>
>
>
> On 08/06/17 23:12, Neetish Pathak wrote:
> > Thanks.
> > I had one query regarding the TLS 1.3 implementation on server
> side. I
> > have a simple client server program with session resumption
> working with
> > TLS 1.2.
> > When I use TLS 1.3, I see that server hello message has a malformed
> > packet.
>
> How do you know it is malformed? The format of the ServerHello message
> has changed in TLSv1.3, so if you expect it to look like a TLSv1.2
> ServerHello then you will be surprised.
>
>
>
> *I know the ServerHello is malformed from the WIRESHARK LOGS. It shows
> an exception for the ServerHello with malformed packet message.*

It is quite likely that your version of wireshark does not know how to
properly decode the TLS 1.3 ServerHello.  When interpreted as a TLS 1.2
ServerHello, it is expected to show as malformed, because the protocol
formats are different between the two protocols.  This is what Matt was
trying to say.

Someone could look at the raw hex dump of the packet and decode it
manually as a TLS 1.3 ServerHello to confirm whether it is actually
malformed or just a wireshark error.

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

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

Thanks Matt

On Thu, Jun 8, 2017 at 3:45 PM, Matt Caswell  wrote:

>
>
> On 08/06/17 23:12, Neetish Pathak wrote:
> > Thanks.
> > I had one query regarding the TLS 1.3 implementation on server side. I
> > have a simple client server program with session resumption working with
> > TLS 1.2.
> > When I use TLS 1.3, I see that server hello message has a malformed
> > packet.
>
> How do you know it is malformed? The format of the ServerHello message
> has changed in TLSv1.3, so if you expect it to look like a TLSv1.2
> ServerHello then you will be surprised.
>


*I know the ServerHello is malformed from the WIRESHARK LOGS. It shows an
exception for the ServerHello with malformed packet message.*


>
> > Though the SSL handshake is successful. I am not observing
> > session resumption.
> > I want to know what causes server hello to have a malformed packet.
> > Also, is any extra configuration required for TLS 1.3 ?
> > I am assuming TLS 1.3 can also use session Ids/ tickets for session
> > resumption.
>
> You probably want to read this blog post:
>
> https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/
>
> *This blogpost is highly useful. Thanks for directing me here. I
am following the guidelines.*


> Session ids are not used in TLSv1.3 and session tickets work very
> differently. Session resumption should work just fine but there are some
> things to be aware of (discussed in the blog post).
>
> Matt
>
>
> >
> > Thanks
> > Best Regards,
> > Neetish
> >
> > On Thu, Jun 8, 2017 at 1:47 AM, Matt Caswell  > > wrote:
> >
> >
> >
> > On 08/06/17 01:26, Neetish Pathak wrote:
> > > Hello All,
> > >
> > > I am new to the Openssl community.
> > > I am using the latest version of Openssl (with TLS 1.3 enabled) for
> > > performance benchmarking. I wanted to know if the session ticket
> support
> > > for session resumption enabled;ed by default for OpenSSL TLS v 1.2
> or it
> > > needs to be explicitly enabled?
> >
> > It is on by default.
> >
> > 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
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Matt Caswell]

On 08/06/17 23:12, Neetish Pathak wrote:
> Thanks. 
> I had one query regarding the TLS 1.3 implementation on server side. I
> have a simple client server program with session resumption working with
> TLS 1.2. 
> When I use TLS 1.3, I see that server hello message has a malformed
> packet.

How do you know it is malformed? The format of the ServerHello message
has changed in TLSv1.3, so if you expect it to look like a TLSv1.2
ServerHello then you will be surprised.

> Though the SSL handshake is successful. I am not observing
> session resumption.
> I want to know what causes server hello to have a malformed packet.
> Also, is any extra configuration required for TLS 1.3 ?
> I am assuming TLS 1.3 can also use session Ids/ tickets for session
> resumption.

You probably want to read this blog post:

https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/

Session ids are not used in TLSv1.3 and session tickets work very
differently. Session resumption should work just fine but there are some
things to be aware of (discussed in the blog post).

Matt


> 
> Thanks
> Best Regards,
> Neetish
> 
> On Thu, Jun 8, 2017 at 1:47 AM, Matt Caswell  > wrote:
> 
> 
> 
> On 08/06/17 01:26, Neetish Pathak wrote:
> > Hello All,
> >
> > I am new to the Openssl community.
> > I am using the latest version of Openssl (with TLS 1.3 enabled) for
> > performance benchmarking. I wanted to know if the session ticket support
> > for session resumption enabled;ed by default for OpenSSL TLS v 1.2 or it
> > needs to be explicitly enabled?
> 
> It is on by default.
> 
> 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

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Neetish Pathak]

Thanks.
I had one query regarding the TLS 1.3 implementation on server side. I have
a simple client server program with session resumption working with TLS
1.2.
When I use TLS 1.3, I see that server hello message has a malformed packet.
Though the SSL handshake is successful. I am not observing session
resumption.
I want to know what causes server hello to have a malformed packet. Also,
is any extra configuration required for TLS 1.3 ?
I am assuming TLS 1.3 can also use session Ids/ tickets for session
resumption.

Thanks
Best Regards,
Neetish

On Thu, Jun 8, 2017 at 1:47 AM, Matt Caswell  wrote:

>
>
> On 08/06/17 01:26, Neetish Pathak wrote:
> > Hello All,
> >
> > I am new to the Openssl community.
> > I am using the latest version of Openssl (with TLS 1.3 enabled) for
> > performance benchmarking. I wanted to know if the session ticket support
> > for session resumption enabled;ed by default for OpenSSL TLS v 1.2 or it
> > needs to be explicitly enabled?
>
> It is on by default.
>
> 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

Re: [openssl-users] Session Ticket Support in Openssl TLS 1.2

[Matt Caswell]

On 08/06/17 01:26, Neetish Pathak wrote:
> Hello All,
> 
> I am new to the Openssl community.
> I am using the latest version of Openssl (with TLS 1.3 enabled) for
> performance benchmarking. I wanted to know if the session ticket support
> for session resumption enabled;ed by default for OpenSSL TLS v 1.2 or it
> needs to be explicitly enabled?

It is on by default.

Matt

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