[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 <bkaduk at akamai.com> wrote:

> On 06/19/2017 04:12 PM, Neetish Pathak wrote:
>
>
>
> On Mon, Jun 19, 2017 at 11:11 AM, Neetish Pathak <npathak2 at ncsu.edu>
> 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 <matt at openssl.org> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170620/8b8ee457/attachment-0001.html>