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