[openssl-users] Session Ticket Support in Openssl TLS 1.2
Neetish Pathak
npathak2 at ncsu.edu
Tue Jun 20 18:52:44 UTC 2017
I Appreciate your response
On Tue, Jun 20, 2017 at 2:09 AM, Matt Caswell <matt at openssl.org> 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 <matt at openssl.org
> > <mailto:matt at openssl.org>> 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 <matt at openssl.org
> <mailto:matt at openssl.org>
> > > <mailto:matt at openssl.org <mailto:matt at openssl.org>>> 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
> > <https://mta.openssl.org/mailman/listinfo/openssl-users>
> >
> >
> >
> >
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170620/3cc804a8/attachment.html>
More information about the openssl-users
mailing list