Hi , I am building a server and client program. I wanted to know if the client intends to use a particular cipher suite ECDHE256 ECDSA 256 types and presents it to the server as its only ciphersuite. Then who decides the Diffie-hellman and EC parameters. Should the parameters be decided on the client side or the server side?
Thanks Best Regards, Neetish On Tue, Jun 27, 2017 at 4:56 PM, Neetish Pathak <npath...@ncsu.edu> wrote: > Thanks > 1) How can i load multiple private keys and certificates on the server > side. > I need to use different keys and certificates when the client explicitly > asks for a particular cipher. > E.g The client can send the ciphersuite as > > ECDHE-RSA-AES256-GCM-SHA384 for first connection > and then > > ECDHE-ECDSA-AES256-GCM-SHA384 for second connection > > Server should pick the right key and certificate (RSA and ECDSA certs > respectively) > > I am using > > SSL_CTX_use_certificate_file to load the certificate but the server always > picks just the first certificate mentioned in the file and fails for one of > the cases with no cipher shared message > > What should we do to store multiple certificates and private keys at the > server side so that it picks the right one corresponding to the requested > cipher. > > > Should I make certificate chain ? > > Should I make keystore? (PKCS12 etc) > > what API should be used to load the keys and certificates. Can somebody > suggest the right way to do this. > Thanks > Best Regards, > Neetish > > > On Tue, Jun 27, 2017 at 12:56 AM, Matt Caswell <m...@openssl.org> wrote: > >> >> >> 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 <npath...@ncsu.edu >> > <mailto:npath...@ncsu.edu>> wrote: >> > >> > >> > >> > On Wed, Jun 21, 2017 at 3:11 AM, Matt Caswell <m...@openssl.org >> > <mailto: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 >> > <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> >> > > <mailto: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> >> > > <mailto: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>> >> > > > <mailto: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>>> >> > > > > <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 <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>> >> > > > >> > <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/mailm >> an/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
