<div dir="ltr">Hi ,<div><br></div><div>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?</div><div><br></div><div>Thanks</div><div>Best Regards,</div><div>Neetish</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 27, 2017 at 4:56 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks<div>1) How can i load multiple private keys and certificates on the server side.</div><div>I need to use different keys and certificates when the client explicitly asks for a particular cipher. </div><div>E.g The client can send the ciphersuite as </div>
<table border="0" cellpadding="0" cellspacing="0" width="273" style="direction:ltr;border-collapse:collapse;width:205pt">
<colgroup><col width="273" style="width:205pt">
</colgroup><tbody><tr height="64" style="height:48pt">
<td height="64" class="m_-3831926591619851111gmail-xl63" width="273" style="height:48pt;width:205pt"><br><div style="direction:ltr">ECDHE-RSA-AES256-GCM-SHA384 for first connection</div><div style="direction:ltr">and then </div><table border="0" cellpadding="0" cellspacing="0" width="264" style="direction:ltr;border-collapse:collapse;width:198pt">
<colgroup><col width="264" style="width:198pt">
</colgroup><tbody><tr height="64" style="height:48pt">
<td height="64" class="m_-3831926591619851111gmail-xl63" width="264" style="height:48pt;width:198pt"><br>
ECDHE-ECDSA-AES256-GCM-SHA384 for second connection<br><br>Server should pick the right key and certificate (RSA and ECDSA certs respectively)<br><br>I am using
<p class="m_-3831926591619851111gmail-p1" style="direction:ltr">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</p><p class="m_-3831926591619851111gmail-p1">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.</p><p class="m_-3831926591619851111gmail-p1"><br></p><p class="m_-3831926591619851111gmail-p1">Should I make certificate chain ? </p><p class="m_-3831926591619851111gmail-p1">Should I make keystore? (PKCS12 etc) </p><p class="m_-3831926591619851111gmail-p1">what API should be used to load the keys and certificates. Can somebody suggest the right way to do this.</p>Thanks<br>Best Regards,<br>Neetish</td>
</tr>
</tbody></table></td>
</tr>
</tbody></table><div style="direction:ltr"> </div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 27, 2017 at 12:56 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
<br>
On 27/06/17 01:05, Neetish Pathak wrote:<br>
> Hi ,<br>
><br>
> 1) I am working with a client and server program and want to use<br>
> ECDHE-ECDSA type ciphers.<br>
> I see that default Elliptic curve group supported is X25519. (when I<br>
> check client and server logs on wireshark)<br>
> I wish to generate a self-signed certificate for X25519 curve. But I am<br>
> unable to do that the way I do for other curves like secp256r1,<br>
> secp521r1 etc.<br>
><br>
> I generate a private key for secp521r1 using ecparam command and then I<br>
> generate the self-signed certificate.<br>
><br>
> openssl ecparam -name secp521r1 -genkey -param_enc named_curve -out<br>
> server_key.pem<br>
><br>
> openssl req -new -x509 -key server_key.pem -out server_cert.pem -days 730<br>
><br>
><br>
> On man page for X25519,<br>
><br>
> I found the command to generate private key<br>
><br>
> openssl genpkey -algorithm X25519 -out xkey.pem<br>
><br>
> But as I try to generate a self signed certificate, I am getting the<br>
> following error<br>
><br>
> EVP_PKEY_sign_init:operation not supported for this keytype<br>
<br>
</span>It is not possible to "self-sign" an X25519 certificate because X25519<br>
is a key-exchange algorithm only, not a digital signature algorithm. You<br>
would not typically create an X25519 certificate at all but an Ed25519<br>
one (only supported in the master branch).<br>
<span><br>
<br>
><br>
><br>
> Could you please clarify where am I going wrong. Also, why is X25519 not<br>
> mentioned<br>
><br>
> in ec curve list<br>
><br>
> using openssl ecparam -list_curves<br>
<br>
</span>X25519 is different. "Standard" EC keys can be used for ECDH or ECDSA.<br>
X25519 keys are for X25519 only (similar to ECDH). Internally X25519 is<br>
treated as a standalone algorithm and not integrated into the rest of<br>
the EC logic.<br>
<span><br>
><br>
><br>
> Any references to clarify my understanding will be appreciated.<br>
><br>
> 2) Also, can you direct me towards what hack is needed in Openssl to<br>
> support pre-generated PSK in TLS 1.3 and false start in TLS 1.2 (for my<br>
> study purpose).<br>
<br>
</span>For external PSKs in TLS1.3 (again only supported in master), you need<br>
to use the new<br>
SSL_CTX_set_psk_use_session_ca<wbr>llback()/SSL_CTX_set_psk_find_<wbr>session_callback()<br>
APIs. See the man pages in master for this (for some reason I notice<br>
that the documentation for this has not been updated on the website -<br>
but it *is* in the doc/man3 folder in git).<br>
<span><br>
><br>
> Are you planning to integrate false start in OpenSSL any time. Thanks<br>
<br>
</span>I am not aware of anyone working on this.<br>
<span><br>
Matt<br>
<br>
<br>
><br>
> Thanks<br>
><br>
><br>
> Best Regards,<br>
> Neetish<br>
><br>
</span><span>> On Wed, Jun 21, 2017 at 3:17 PM, Neetish Pathak <<a href="mailto:npathak2@ncsu.edu" target="_blank">npathak2@ncsu.edu</a><br>
</span><span>> <mailto:<a href="mailto:npathak2@ncsu.edu" target="_blank">npathak2@ncsu.edu</a>>> wrote:<br>
><br>
><br>
><br>
> On Wed, Jun 21, 2017 at 3:11 AM, Matt Caswell <<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a><br>
</span><div><div class="m_-3831926591619851111h5">> <mailto:<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a>>> wrote:<br>
><br>
><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>
> <<a href="https://github.com/openssl/openssl/issues/1541" rel="noreferrer" target="_blank">https://github.com/openssl/o<wbr>penssl/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>
> No, it is encrypted using a traffic key derived from the PSK.<br>
><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>
> The same PSK can be used multiple times. Because the traffic key<br>
> for the<br>
> early data is derived from the PSK, if you later re-use the PSK<br>
> and send<br>
> early data again then the same traffic key will be derived. This<br>
> can be<br>
> exploited by an attacker who can record the early data from an<br>
> 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<br>
> 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<br>
> defines its<br>
> use. That profile needs to identify which messages or<br>
> interactions<br>
> are safe to use with 0-RTT. In addition, to avoid accidental<br>
> 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<br>
> it is<br>
> sending or receiving data that might be replayed.<br>
><br>
><br>
> ><br>
> > Is there any API available in OpenSSL for false start ?<br>
><br>
> No, OpenSSL does not support false start. As an aside please<br>
> note that<br>
> false start only applies to <= TLSv1.2.<br>
><br>
><br>
> Thanks for your comments.<br>
><br>
> I need some direction on the doing server and client side<br>
> authentication during the handshake.<br>
><br>
</div></div>> *1) For certificate sent from the server side, I am using*<br>
<span>><br>
> SSL_CTX_load_verify_<wbr>locations(ssl_ctx, CAFILE, NULL)) for loading<br>
</span>> verification file *on the client side*<br>
<span>><br>
> Where do I get a CAFILE in the above API. If the server is sending a<br>
> self signed certificate, what will be the CA file on the client side<br>
> for verification.<br>
><br>
><br>
</span>> *2) For Client side authentication*<br>
> *<br>
> *<br>
<span>> I am using SSL_CTX_use_PrivateKey_file and SSL_CTX_use_certificate<br>
> file on the client side to load the private key and the certificate.<br>
> I read that client side authentication will not kick off unless the<br>
> server sends CertificateRequest. I can use<br>
> SSL_CTX_set_client_cert_cb() that sets the client_cert_cb()callback<br>
> to be called on CertificateRequest.<br>
><br>
> I am not sure how I can enable the server side to send<br>
> CertificateRequest. What is the API for that.<br>
> Should SSL_CTX_set_verify((ssl_ctx,SS<wbr>L_VERIFY_PEER, NULL)) be used<br>
> on server side for sending the certificateRequest message. Please<br>
> correct me ?<br>
><br>
</span>> *3) Certificate request Message*<br>
<span class="m_-3831926591619851111im m_-3831926591619851111HOEnZb">> Also, what is the use of CertificateVerify message. Why does client<br>
> need to prove the ownership of private key for the public key sent<br>
> previously in the client certificate. I assume this is not happening<br>
> when the server sends the certificate. It doesn't prove the<br>
> ownership of private key.Please comment<br>
><br>
><br>
><br>
> Also, some guidance on a reference for understanding the<br>
> authentication of certificates will be appreciated<br>
><br>
><br>
> Thanks<br>
> Neetish<br>
><br>
><br>
><br>
><br>
> Matt<br>
><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> <mailto:<a href="mailto:npathak2@ncsu.edu" target="_blank">npathak2@ncsu.edu</a>><br>
</span><span class="m_-3831926591619851111im m_-3831926591619851111HOEnZb">> > <mailto:<a href="mailto:npathak2@ncsu.edu" target="_blank">npathak2@ncsu.edu</a> <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> <mailto:<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a>><br>
</span><span class="m_-3831926591619851111im m_-3831926591619851111HOEnZb">> > <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 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>
> <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>
</span><div class="m_-3831926591619851111HOEnZb"><div class="m_-3831926591619851111h5">> > > <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 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<br>
> <<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>>>><br>
> > > > <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>>><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<br>
> openssl-users<br>
> > wrote:<br>
> > > > > On 06/16/2017 01:58 PM, Neetish Pathak<br>
> wrote:<br>
> > > > >> Hello<br>
> > > > >> Thanks<br>
> > > > >> I tried reading some content from the<br>
> server<br>
> > side and I<br>
> > > observed the<br>
> > > > >> new_session_cb getting invoked in that<br>
> case on<br>
> > the client<br>
> > > side. I<br>
> > > > >> understand that may be due to delayed<br>
> NewSession info<br>
> > > transfer from<br>
> > > > >> server side to client side. But it is<br>
> helpful for<br>
> > saving<br>
> > > the session<br>
> > > > >> info on the client side. (Thanks Matt<br>
> for your input)<br>
> > > > >><br>
> > > > >> However, now I have two concerns<br>
> > > > >><br>
> > > > >> 1) I see that latency for handshake<br>
> with session<br>
> > resumption in<br>
> > > > TLS 1.3<br>
> > > > >> has not improved as much as it improves<br>
> for TLS 1.2<br>
> > > > >> With TLS 1.3, I observed that<br>
> 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<br>
> session IDs or<br>
> > tickets), the<br>
> > > > >> connection time reduces from 2.5 ms to<br>
> 0.5-0.6 ms.<br>
> > > > >><br>
> > > > >> The whole code is similar for running<br>
> the two<br>
> > experiments<br>
> > > with only<br>
> > > > >> max TLS version changed. Can someone<br>
> comment on<br>
> > the latency<br>
> > > > >> measurements for the two cases.<br>
> > > > >> TLS 1.3 is supposed to be better than<br>
> 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<br>
> 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<br>
> 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<br>
> timer after the<br>
> > > session ticket<br>
> > > > data has been received by the client then<br>
> this is<br>
> > not a "fair"<br>
> > > test (the<br>
> > > > connection is ready for data transfer<br>
> earlier than<br>
> > the arrival<br>
> > > of the<br>
> > > > session ticket).<br>
> > > ><br>
> > > > I would expect to see the TLS1.3 latency<br>
> 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.<br>
> There are the same<br>
> > > number of round<br>
> > > > trips for a TLS1.3 full handshake as that<br>
> there are<br>
> > for a<br>
> > > resumption<br>
> > > > one. The primary difference is that the<br>
> Certificate<br>
> > message is<br>
> > > not sent<br>
> > > > (which can be quite a large message).<br>
> > > ><br>
> > > > Your timings suggest you are testing this<br>
> over a LAN<br>
> > where the<br>
> > > effects<br>
> > > > of network latency are going to be<br>
> relatively low.<br>
> > The real<br>
> > > benefits<br>
> > > > from fewer round trips will really be seen<br>
> when network<br>
> > > latency is more<br>
> > > > significant.<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > In my application program, I put start and<br>
> 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<br>
> also be<br>
> > including the<br>
> > > subsequent session ticket transfer).<br>
> > ><br>
> > > > I am not sure how I can put timers at<br>
> individual steps<br>
> > of Handshake<br>
> > > > using my client applications. I was assuming<br>
> SSL and<br>
> > SSL_accept take<br>
> > > > care of the entire handshake process.<br>
> > > ><br>
> > > > Yes, I am testing on local machine. I will<br>
> migrate my<br>
> > test to remote<br>
> > > > machines. But I am not really able to<br>
> 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<br>
> to reduce<br>
> > the number of<br>
> > > round-trips required in order to avoid<br>
> 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<br>
> 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<br>
> exchange<br>
> > algorithms,<br>
> > > curves etc between TLSv1.2 and TLSv1.3.<br>
> Differences in any<br>
> > one of these<br>
> > > could obviously have significant performance<br>
> impacts.<br>
> > ><br>
> > > Matt<br>
> > ><br>
> > > --<br>
> > > openssl-users mailing list<br>
> > > To unsubscribe:<br>
> > ><br>
> <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>
> <<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>
> <<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>
> <<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>
> <<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>
> > --<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>
> <<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:<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>
><span class="HOEnZb"><font color="#888888"><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>
</font></span></div></div></blockquote></div><br></div></div>
</blockquote></div><br></div>