[openssl-users] Session Ticket Support in Openssl TLS 1.2
Neetish Pathak
npathak2 at ncsu.edu
Wed Jun 21 22:17:12 UTC 2017
On Wed, Jun 21, 2017 at 3:11 AM, Matt Caswell <matt at openssl.org> 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 <npathak2 at ncsu.edu
> > <mailto:npathak2 at ncsu.edu>> wrote:
> >
> > I Appreciate your response
> >
> > On Tue, Jun 20, 2017 at 2:09 AM, Matt Caswell <matt at openssl.org
> > <mailto: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>
> > > <mailto: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>>
> > > > <mailto: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>
> > > <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
> > <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/20170621/274d8d6d/attachment-0001.html>
More information about the openssl-users
mailing list