On Wed, Jun 21, 2017 at 3:11 AM, Matt Caswell <m...@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 <npath...@ncsu.edu > > <mailto:npath...@ncsu.edu>> wrote: > > > > I Appreciate your response > > > > On Tue, Jun 20, 2017 at 2:09 AM, Matt Caswell <m...@openssl.org > > <mailto:m...@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 < > m...@openssl.org <mailto:m...@openssl.org> > > > <mailto:m...@openssl.org <mailto:m...@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 < > m...@openssl.org <mailto:m...@openssl.org> > > <mailto:m...@openssl.org <mailto:m...@openssl.org>> > > > > <mailto:m...@openssl.org <mailto:m...@openssl.org> > > <mailto:m...@openssl.org <mailto:m...@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 >
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users