Re: Session Ticket Support in Openssl TLS 1.2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I Appreciate your response

On Tue, Jun 20, 2017 at 2:09 AM, Matt Caswell <matt@xxxxxxxxxxx> 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@xxxxxxxxxxx
> <mailto:matt@xxxxxxxxxxx>> 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@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx>
>     > <mailto:matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx>>> 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

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux