On 27/06/17 01:05, Neetish Pathak wrote: > Hi , > > 1) I am working with a client and server program and want to use > ECDHE-ECDSA type ciphers. > I see that default Elliptic curve group supported is X25519. (when I > check client and server logs on wireshark) > I wish to generate a self-signed certificate for X25519 curve. But I am > unable to do that the way I do for other curves like secp256r1, > secp521r1 etc. > > I generate a private key for secp521r1 using ecparam command and then I > generate the self-signed certificate. > > openssl ecparam -name secp521r1 -genkey -param_enc named_curve -out > server_key.pem > > openssl req -new -x509 -key server_key.pem -out server_cert.pem -days 730 > > > On man page for X25519, > > I found the command to generate private key > > openssl genpkey -algorithm X25519 -out xkey.pem > > But as I try to generate a self signed certificate, I am getting the > following error > > EVP_PKEY_sign_init:operation not supported for this keytype It is not possible to "self-sign" an X25519 certificate because X25519 is a key-exchange algorithm only, not a digital signature algorithm. You would not typically create an X25519 certificate at all but an Ed25519 one (only supported in the master branch). > > > Could you please clarify where am I going wrong. Also, why is X25519 not > mentioned > > in ec curve list > > using openssl ecparam -list_curves X25519 is different. "Standard" EC keys can be used for ECDH or ECDSA. X25519 keys are for X25519 only (similar to ECDH). Internally X25519 is treated as a standalone algorithm and not integrated into the rest of the EC logic. > > > Any references to clarify my understanding will be appreciated. > > 2) Also, can you direct me towards what hack is needed in Openssl to > support pre-generated PSK in TLS 1.3 and false start in TLS 1.2 (for my > study purpose). For external PSKs in TLS1.3 (again only supported in master), you need to use the new SSL_CTX_set_psk_use_session_callback()/SSL_CTX_set_psk_find_session_callback() APIs. See the man pages in master for this (for some reason I notice that the documentation for this has not been updated on the website - but it *is* in the doc/man3 folder in git). > > Are you planning to integrate false start in OpenSSL any time. Thanks I am not aware of anyone working on this. Matt > > Thanks > > > Best Regards, > Neetish > > On Wed, Jun 21, 2017 at 3:17 PM, Neetish Pathak <npathak2@xxxxxxxx > <mailto:npathak2@xxxxxxxx>> wrote: > > > > On Wed, Jun 21, 2017 at 3:11 AM, Matt Caswell <matt@xxxxxxxxxxx > <mailto:matt@xxxxxxxxxxx>> 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 > <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@xxxxxxxx <mailto:npathak2@xxxxxxxx> > > <mailto:npathak2@xxxxxxxx <mailto:npathak2@xxxxxxxx>>> wrote: > > > > I Appreciate your response > > > > On Tue, Jun 20, 2017 at 2:09 AM, Matt Caswell <matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx> > > <mailto:matt@xxxxxxxxxxx <mailto: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> > <mailto:matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx>> > > > <mailto:matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx> > <mailto: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>> > > <mailto:matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx> > <mailto:matt@xxxxxxxxxxx <mailto:matt@xxxxxxxxxxx>>> > > > > <mailto:matt@xxxxxxxxxxx > <mailto:matt@xxxxxxxxxxx> <mailto:matt@xxxxxxxxxxx > <mailto:matt@xxxxxxxxxxx>> > > <mailto: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> > > > <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> > > > <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> > > > <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
