<div dir="ltr"><div class="gmail_extra">Hi ,</div><div class="gmail_extra"><br></div><div class="gmail_extra">1) I am working with a client and server program and want to use ECDHE-ECDSA type ciphers.</div><div class="gmail_extra">I see that default Elliptic curve group supported is X25519. (when I check client and server logs on wireshark)</div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I generate a private key for secp521r1 using ecparam command and then I generate the self-signed certificate.</div><div class="gmail_extra"><br></div><div class="gmail_extra">openssl ecparam -name secp521r1 -genkey -param_enc named_curve -out server_key.pem</div><div class="gmail_extra">
<p class="gmail-p1"><span class="gmail-s1">openssl req -new -x509 -key server_key.pem -out server_cert.pem -days 730</span></p><p class="gmail-p1"><span class="gmail-s1"><br></span></p><p class="gmail-p1"><span class="gmail-s1">On man page for X25519,</span></p><p class="gmail-p1"><span class="gmail-s1">I found the command to generate private key</span></p><p class="gmail-p1"><span class="gmail-s1">
</span></p><p class="gmail-p1"><span class="gmail-s1">openssl genpkey -algorithm X25519 -out xkey.pem</span></p><p class="gmail-p1"><span class="gmail-s1">But as I try to generate a self signed certificate, I am getting the following error</span></p><p class="gmail-p1"><span class="gmail-s1">
</span></p><p class="gmail-p1"><span class="gmail-s1">EVP_PKEY_sign_init:operation not supported for this keytype</span></p><p class="gmail-p1"><span class="gmail-s1"><br></span></p><p class="gmail-p1"><span class="gmail-s1">Could you please clarify where am I going wrong. Also, why is X25519 not mentioned</span></p><p class="gmail-p1"><span class="gmail-s1">in ec curve list</span></p><p class="gmail-p1"><span class="gmail-s1">using openssl ecparam -list_curves</span></p><p class="gmail-p1"><span class="gmail-s1"><br></span></p><p class="gmail-p1"><span class="gmail-s1">Any references to clarify my understanding will be appreciated.</span></p><p class="gmail-p1"><span class="gmail-s1">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). </span></p><p class="gmail-p1"><span class="gmail-s1">Are you planning to integrate false start in OpenSSL any time. Thanks</span></p><p class="gmail-p1"><span class="gmail-s1">Thanks</span></p><p class="gmail-p1"><span class="gmail-s1"><br></span></p></div><div class="gmail_extra">Best Regards,</div><div class="gmail_extra">Neetish</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 21, 2017 at 3:17 PM, Neetish Pathak <span dir="ltr"><<a href="mailto:npathak2@ncsu.edu" target="_blank">npathak2@ncsu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="gmail-h5">On Wed, Jun 21, 2017 at 3:11 AM, Matt Caswell <span dir="ltr"><<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_8339877847428487498gmail-"><br>
<br>
On 21/06/17 00:38, Neetish Pathak wrote:<br>
> I wanted to understand the replay attack vulnerability in case of enable<br>
> early data of TLS 1.3 while false start is secure in that respect as I<br>
> have read from <a href="https://github.com/openssl/openssl/issues/1541" rel="noreferrer" target="_blank">https://github.com/openssl/ope<wbr>nssl/issues/1541</a><br>
> So, with false start, the application data is sent from client after the<br>
> first leg of the handshake i.e. one round trip is complete, so the data<br>
> goes encrypted even though the handshake is not completed. In enable<br>
> early data mode in TLS 1.3 for 0-RTT for session resumption, the<br>
> application data is sent from the client along with the client hello<br>
> message. Does the application data in early data mode go as clear text ?<br>
<br>
</span>No, it is encrypted using a traffic key derived from the PSK.<br>
<span class="gmail-m_8339877847428487498gmail-"><br>
> I assume this is also encrypted using the PSK because 0-RTT is only<br>
> applicable when PSK is available on the client side. How is it<br>
> vulnerable to replay attack. Please help me understand.<br>
<br>
</span>The same PSK can be used multiple times. Because the traffic key for the<br>
early data is derived from the PSK, if you later re-use the PSK and send<br>
early data again then the same traffic key will be derived. This can be<br>
exploited by an attacker who can record the early data from an earlier<br>
session and replay it later. The server will think that the replayed<br>
data is a new connection and process the early data accordingly.<br>
<br>
Early data (aka 0-RTT data) can be dangerous if not used properly. For<br>
this reason the current TLSv1.3 draft makes this note:<br>
<br>
Protocols MUST NOT use 0-RTT data without a profile that defines its<br>
use. That profile needs to identify which messages or interactions<br>
are safe to use with 0-RTT. In addition, to avoid accidental misuse,<br>
implementations SHOULD NOT enable 0-RTT unless specifically<br>
requested. Implementations SHOULD provide special functions for<br>
0-RTT data to ensure that an application is always aware that it is<br>
sending or receiving data that might be replayed.<br>
<span class="gmail-m_8339877847428487498gmail-"><br>
<br>
><br>
> Is there any API available in OpenSSL for false start ?<br>
<br>
</span>No, OpenSSL does not support false start. As an aside please note that<br>
false start only applies to <= TLSv1.2.</blockquote><div><br></div></div></div><div>Thanks for your comments.</div><div><br></div><div>I need some direction on the doing server and client side authentication during the handshake. </div><div><br></div><div><b>1) For certificate sent from the server side, I am using</b> </div><div>
<p class="gmail-m_8339877847428487498gmail-p1">SSL_CTX_load_verify_locations(<wbr>ssl_ctx, CAFILE, NULL)) for loading verification file <b>on the client side</b></p><p class="gmail-m_8339877847428487498gmail-p1">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. </p>
<p class="gmail-m_8339877847428487498gmail-p1"><br></p></div><div><b>2) For Client side authentication</b></div><div><b><br></b></div><div>I am using <span style="font-family:Courier;font-size:14px">SSL_CTX_use_PrivateKey_<wbr>file and SSL_CTX_use_certificate file on the client side to load the private key and the certificate. </span></div><div><span style="font-family:Courier;font-size:14px">I read that client side authentication will not kick off unless the server sends CertificateRequest. I can use </span><span class="gmail-m_8339877847428487498gmail-s1" style="color:rgb(0,0,0);font-family:Menlo;font-size:11px">SSL_CTX_set_client_cert_cb()</span><span class="gmail-m_8339877847428487498gmail-s2" style="color:rgb(0,0,0);font-family:Menlo;font-size:11px"> <wbr>that sets the </span><span class="gmail-m_8339877847428487498gmail-s1" style="color:rgb(0,0,0);font-family:Menlo;font-size:11px">client_cert_cb()</span><span class="gmail-m_8339877847428487498gmail-s2" style="color:rgb(0,0,0);font-family:Menlo;font-size:11px"> callback to be called on CertificateRequest.</span></div><div><span class="gmail-m_8339877847428487498gmail-s2" style="color:rgb(0,0,0);font-family:Menlo;font-size:11px"><br></span></div><div><font color="#000000" face="Menlo"><span style="font-size:11px">I am not sure how I can enable the server side to send CertificateRequest. What is the API for that.</span></font></div><div><font color="#000000" face="Menlo"><span style="font-size:11px">Should SSL_CTX_set_verify(</span></font>(ssl_ctx,<wbr>SSL_VERIFY_PEER, NULL)<span style="font-size:11px;color:rgb(0,0,0);font-family:Menlo">) be used on server side for sending the certificateRequest message. Please correct me ?</span></div><div><font color="#000000" face="Menlo"><span style="font-size:11px"><br></span></font></div><div><font color="#000000" face="Menlo"><span style="font-size:11px"><b>3) Certificate request Message</b></span></font></div><div><font color="#000000" face="Menlo"><span style="font-size:11px">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</span></font></div><div><font color="#000000" face="Menlo"><span style="font-size:11px"><br></span></font></div><div><font color="#000000" face="Menlo"><span style="font-size:11px"><br></span></font></div><div><font color="#000000" face="Menlo"><span style="font-size:11px"><br></span></font></div><div><font color="#000000" face="Menlo"><span style="font-size:11px">Also, some guidance on a reference for understanding the authentication of certificates will be appreciated </span></font></div><div><font color="#000000" face="Menlo"><span style="font-size:11px"><br></span></font></div><div><font color="#000000" face="Menlo"><span style="font-size:11px"><br></span></font></div><div><font color="#000000" face="Menlo"><span style="font-size:11px">Thanks</span></font></div><span class="gmail-HOEnZb"><font color="#888888"><div><font color="#000000" face="Menlo"><span style="font-size:11px">Neetish</span></font></div></font></span><div><div class="gmail-h5">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-m_8339877847428487498gmail-HOEnZb"><font color="#888888"><br>
<br>
Matt<br>
</font></span><span class="gmail-m_8339877847428487498gmail-im gmail-m_8339877847428487498gmail-HOEnZb"><br>
><br>
> Thanks<br>
> Best regards,<br>
> Neetish<br>
><br>
> On Tue, Jun 20, 2017 at 11:52 AM, Neetish Pathak <<a href="mailto:npathak2@ncsu.edu" target="_blank">npathak2@ncsu.edu</a><br>
</span><span class="gmail-m_8339877847428487498gmail-im gmail-m_8339877847428487498gmail-HOEnZb">> <mailto:<a href="mailto:npathak2@ncsu.edu" target="_blank">npathak2@ncsu.edu</a>>> wrote:<br>
><br>
> I Appreciate your response<br>
><br>
> On Tue, Jun 20, 2017 at 2:09 AM, Matt Caswell <<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a><br>
</span><span class="gmail-m_8339877847428487498gmail-im gmail-m_8339877847428487498gmail-HOEnZb">> <mailto:<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a>>> wrote:<br>
><br>
><br>
><br>
> On 19/06/17 19:11, Neetish Pathak wrote:<br>
> > 2) Can you suggest some places to put a time stamp in OpenSSL code.<br>
><br>
> I agree with Ben's responses to all your other questions. For this<br>
> question, I'm not sure what you are trying to achieve? Starting<br>
> before<br>
> SSL_accept/SSL_connect and finishing after they return should be<br>
> fine.<br>
> Or are you looking for a breakdown of where the time is going?<br>
><br>
> Thanks Matt. I was asking for a breakdown since I was not sure<br>
> if the SSL_accept and SSL_connect just do the handshake or if<br>
> they are doing some other things that may impact latency and CPU<br>
> usage. Just wanted to be clear that calling SSL_connect starts<br>
> ClientHello , SSL_accept unblocks on receiving ClientHello and<br>
> sends ServerHello, and both functions return after sending<br>
> Finished message from their sides (i.e. client and server).<br>
><br>
><br>
><br>
><br>
><br>
> Matt<br>
><br>
> ><br>
> > Thanks<br>
> > Best Regards,<br>
> > Neetish<br>
> ><br>
> > On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell <<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a> <mailto:<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a>><br>
</span><div class="gmail-m_8339877847428487498gmail-HOEnZb"><div class="gmail-m_8339877847428487498gmail-h5">> > <mailto:<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a> <mailto:<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a>>>> wrote:<br>
> ><br>
> ><br>
> ><br>
> > On 16/06/17 23:51, Neetish Pathak wrote:<br>
> > > Thanks Matt, Appreciate ur response and tips<br>
> > ><br>
> > > On Fri, Jun 16, 2017 at 3:36 PM, Matt Caswell <<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a> <mailto:<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a>><br>
> <mailto:<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a> <mailto:<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a>>><br>
> > > <mailto:<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a> <mailto:<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a>><br>
> <mailto:<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a> <mailto:<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a>>>>> wrote:<br>
> > ><br>
> > ><br>
> > ><br>
> > > On 16/06/17 20:08, Benjamin Kaduk via openssl-users<br>
> wrote:<br>
> > > > On 06/16/2017 01:58 PM, Neetish Pathak wrote:<br>
> > > >> Hello<br>
> > > >> Thanks<br>
> > > >> I tried reading some content from the server<br>
> side and I<br>
> > observed the<br>
> > > >> new_session_cb getting invoked in that case on<br>
> the client<br>
> > side. I<br>
> > > >> understand that may be due to delayed NewSession info<br>
> > transfer from<br>
> > > >> server side to client side. But it is helpful for<br>
> saving<br>
> > the session<br>
> > > >> info on the client side. (Thanks Matt for your input)<br>
> > > >><br>
> > > >> However, now I have two concerns<br>
> > > >><br>
> > > >> 1) I see that latency for handshake with session<br>
> resumption in<br>
> > > TLS 1.3<br>
> > > >> has not improved as much as it improves for TLS 1.2<br>
> > > >> With TLS 1.3, I observed that resumption brings<br>
> down the<br>
> > connection<br>
> > > >> time from 2.5 ms to 1.2-1.3 ms<br>
> > > >> while with TLS 1.2 (using either session IDs or<br>
> tickets), the<br>
> > > >> connection time reduces from 2.5 ms to 0.5-0.6 ms.<br>
> > > >><br>
> > > >> The whole code is similar for running the two<br>
> experiments<br>
> > with only<br>
> > > >> max TLS version changed. Can someone comment on<br>
> the latency<br>
> > > >> measurements for the two cases.<br>
> > > >> TLS 1.3 is supposed to be better than TLS 1.2 in my<br>
> > opinion. Please<br>
> > > >> comment.<br>
> > > >><br>
> > > ><br>
> > > > Are you seeing a HelloRetryRequest in the<br>
> resumption flow?<br>
> > That would<br>
> > > > add an additional round trip. (Your numbers in<br>
> milliseconds<br>
> > are of<br>
> > > > course not transferrable to other systems;<br>
> round-trips is an<br>
> > easier to<br>
> > > > understand number.) RFC 5246 and<br>
> draft-ietf-tls-tls13-20<br>
> > both have<br>
> > > > message-flow diagrams that show the number of<br>
> round trips in<br>
> > various<br>
> > > > handshake flows.<br>
> > ><br>
> > > Care should also be taken about when you are<br>
> starting your<br>
> > "timer" and<br>
> > > when you stop it, e.g. if you stop your timer after the<br>
> > session ticket<br>
> > > data has been received by the client then this is<br>
> not a "fair"<br>
> > test (the<br>
> > > connection is ready for data transfer earlier than<br>
> the arrival<br>
> > of the<br>
> > > session ticket).<br>
> > ><br>
> > > I would expect to see the TLS1.3 latency for a full<br>
> handshake<br>
> > to be<br>
> > > around the same as for a TLS1.2 resumption<br>
> handshake. With a<br>
> > TLS1.3<br>
> > > resumption only marginally different. There are the same<br>
> > number of round<br>
> > > trips for a TLS1.3 full handshake as that there are<br>
> for a<br>
> > resumption<br>
> > > one. The primary difference is that the Certificate<br>
> message is<br>
> > not sent<br>
> > > (which can be quite a large message).<br>
> > ><br>
> > > Your timings suggest you are testing this over a LAN<br>
> where the<br>
> > effects<br>
> > > of network latency are going to be relatively low.<br>
> The real<br>
> > benefits<br>
> > > from fewer round trips will really be seen when network<br>
> > latency is more<br>
> > > significant.<br>
> > ><br>
> > ><br>
> > ><br>
> > > In my application program, I put start and stop timer<br>
> before and after<br>
> > > SSL_accept on server side and before and after<br>
> SSL_connect on the<br>
> > client<br>
> > > side.<br>
> ><br>
> > That should be fine (my worry was that you might also be<br>
> including the<br>
> > subsequent session ticket transfer).<br>
> ><br>
> > > I am not sure how I can put timers at individual steps<br>
> of Handshake<br>
> > > using my client applications. I was assuming SSL and<br>
> SSL_accept take<br>
> > > care of the entire handshake process.<br>
> > ><br>
> > > Yes, I am testing on local machine. I will migrate my<br>
> test to remote<br>
> > > machines. But I am not really able to understand why TLS<br>
> 1.3 is slower<br>
> > > on my machine.<br>
> ><br>
> > If you are on a local machine I would not expect a<br>
> significant speed up<br>
> > in TLSv1.3 vs TLSv1.2. TLSv1.3 has been designed to reduce<br>
> the number of<br>
> > round-trips required in order to avoid unnecessary network<br>
> latency. If<br>
> > you are on a local machine then there isn't any<br>
> significant network<br>
> > latency anyway - so timings are presumably dominated by<br>
> the CPU<br>
> > intensive tasks. You should make sure that you are<br>
> comparing like with<br>
> > like, i.e. the same ciphers, key lengths, key exchange<br>
> algorithms,<br>
> > curves etc between TLSv1.2 and TLSv1.3. Differences in any<br>
> one of these<br>
> > could obviously have significant performance impacts.<br>
> ><br>
> > Matt<br>
> ><br>
> > --<br>
> > openssl-users mailing list<br>
> > To unsubscribe:<br>
> > <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/mailm<wbr>an/listinfo/openssl-users</a><br>
> <<a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/mail<wbr>man/listinfo/openssl-users</a>><br>
> > <<a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/mail<wbr>man/listinfo/openssl-users</a><br>
> <<a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/mail<wbr>man/listinfo/openssl-users</a>>><br>
> ><br>
> ><br>
> ><br>
> ><br>
> --<br>
> openssl-users mailing list<br>
> To unsubscribe:<br>
> <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/mailm<wbr>an/listinfo/openssl-users</a><br>
> <<a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/mail<wbr>man/listinfo/openssl-users</a>><br>
><br>
><br>
><br>
--<br>
openssl-users mailing list<br>
To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/mailma<wbr>n/listinfo/openssl-users</a><br>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div>