Re: [openssl.org #3608] SEGV Crash in dtls1_retransmit_message function
Hi Matt
See inline ..
On Wed, Nov 26, 2014 at 3:52 PM, Matt Caswell via RT r...@openssl.org wrote:
On 25/11/14 23:20, Praveen Kariyanahalli wrote:
Hi Matt
Trying out your patch. Will keep you posted. In meanwhile we ran into
more valgrind issues .. on the server end. Can you please comment on
them?
==621== 8,680 (1,488 direct, 7,192 indirect) bytes in 62 blocks are
definitely lost in loss record 899 of 952
==621==at 0x4A05F80: malloc (vg_replace_malloc.c:296)
==621==by 0x5BFCC86: default_malloc_ex (mem.c:79)
==621==by 0x5BFD315: CRYPTO_malloc (mem.c:308)
==621==by 0x5D2414D: pitem_new (pqueue.c:73)
==621==by 0x5958F74: dtls1_buffer_message (d1_both.c:1233)
==621==by 0x594E3B2: dtls1_send_server_done (d1_srvr.c:1032)
This doesn't look right. The code is sending a ServerHelloDone message
here, but...
==621==by 0x594D696: dtls1_accept (d1_srvr.c:564)
==621==by 0x595C555: SSL_accept (ssl_lib.c:940)
==621==by 0x59539F7: dtls1_listen (d1_lib.c:491)
...here you have entered dtls1_listen.
This internal function gets called when you call the public API function
DTLSv1_listen - which is actually implemented as a macro that calls
SSL_ctrl - which explains the rest of the stack trace below:
[praveen] Agreed.
==621==by 0x59533BF: dtls1_ctrl (d1_lib.c:267)
==621==by 0x595CAF2: SSL_ctrl (ssl_lib.c:1106)
==621==by 0x416229: server_ssl_event_cb (server.c:3823)
The purpose of DTLSv1_listen is to listen for incoming datagrams from
anyone. If it receives a ClientHello without a cookie it immediately
responds with a HelloVerifyRequest containing a cookie. The client is
expected to respond with a second ClientHello containing the cookie. The
idea is that this is a DoS protection mechanism.
If DTLSv1_listen receives a ClientHello *with* a cookie then it will
return with a positive result. The server is then expected to continue
the handshake with a call to SSL_accept. This is often done in a
separate thread just for that SSL_accept call.
So something like this:
while(1)
{
ssl = SSL_new(ctx);
while(DTLSv1_listen(ssl, client_addr) = 0);
/* client_addr will contain ip address of the client */
Create_a_thread(ssl);
}
In new thread:
SSL_accept(ssl);
[praveen]
Yes we do use the DTLS_listen in the same way, only difference being we are
not doing SSL_accept in a new thread. *Note we are doing it in NON blocking
fashion. *The main DTLSv1_listen responds with HelloVerify. When the next
client hello comes back in, the DTLSv1_listen returns a positive result and
then, we create a new socket and pass on the ssl context to this socket (*Note:
it is a connected socket, meaning more specific socket*). We create a new
event corresponding to this socket and call the SSL_do_handshake on this
socket. Then we create a new fd less specific for the listening socket
(server socket).
*Reiterating: Non blocking and single threaded server*
Similar to what is suggested in page number 9
http://sctp.fh-muenster.de/DTLS.pdf
Also note that the cookie is global and periodically changing .. having a
tolerance of accepting previous cookie.
Hope that clarifies.
Regards
-Praveen
Now under the covers DTLSv1_listen calls dlts1_listen which calls
SSL_accept. The difference being that it has set various flags etc to
put it into the listen state.
In your stack trace you are sending a ServerHelloDone, which suggests to
me you are attempting to *complete* a handshake whilst in DTLSv1_listen.
So, in other words, in the above example once you have completed the
initial part of the handshake, you are completing it by calling
DTLSv1_listen again instead of calling SSL_accept (this will at least
look like its working because DTLSv1_listen does eventually call
SSL_accept).
Its not clear to me what will happen in that scenario...at best the
behaviour is undefined (we should probably put a check in to prevent
this from happening...if that is indeed what is going on). I'm not sure
whether that is the cause of this memory leak or not, but it certainly
won't help track it down.
Can you confirm whether you are using DTLSv1_listen like this or not? If
not something really weird is going on.
Matt
--
Regards
-Praveen
[openssl.org #3613] Patch: Fix warning in Nginx logs on every connect when GOST TLS used.
Hello, As noted here: https://groups.google.com/forum/#!topic/mailing.openssl.dev/Ng3xI7-xZ0E all version of OpenSSL produce scary warning in nginx logs on every connect, if GOST TLS used: [alert] 25532#0: *28 ignoring stale global SSL error (SSL: error:140DD112:SSL routines:SSL_CERT_DUP:library bug) while SSL handshaking All trivial fixes are in ssl_cert_dup() function. Please find patch attached. It can be applied using git apply command. 0001-Update-ssl_cert_dup-for-GOST-key.-Nginx-warning-in-l.patch Description: Binary data
Re: [openssl.org #3608] SEGV Crash in dtls1_retransmit_message function
On 27/11/14 02:54, Praveen Kariyanahalli via RT wrote:
The purpose of DTLSv1_listen is to listen for incoming datagrams from
anyone. If it receives a ClientHello without a cookie it immediately
responds with a HelloVerifyRequest containing a cookie. The client is
expected to respond with a second ClientHello containing the cookie. The
idea is that this is a DoS protection mechanism.
If DTLSv1_listen receives a ClientHello *with* a cookie then it will
return with a positive result. The server is then expected to continue
the handshake with a call to SSL_accept. This is often done in a
separate thread just for that SSL_accept call.
So something like this:
while(1)
{
ssl = SSL_new(ctx);
while(DTLSv1_listen(ssl, client_addr) = 0);
/* client_addr will contain ip address of the client */
Create_a_thread(ssl);
}
In new thread:
SSL_accept(ssl);
[praveen]
Yes we do use the DTLS_listen in the same way, only difference being we are
not doing SSL_accept in a new thread. *Note we are doing it in NON blocking
fashion. *The main DTLSv1_listen responds with HelloVerify. When the next
client hello comes back in, the DTLSv1_listen returns a positive result and
then, we create a new socket and pass on the ssl context to this socket
(*Note:
it is a connected socket, meaning more specific socket*). We create a new
event corresponding to this socket and call the SSL_do_handshake on this
socket. Then we create a new fd less specific for the listening socket
(server socket).
I don't quite understand what you are saying here: we do use the
DTLS_listen in the same way. Are you saying you handle the initial
listen part of the handshake with DTLSv1_listen and then call
SSL_accept on the connected socket? Because this suggests you are
calling DTLSv1_listen a second time (i.e. on a handshake that has
already completed the initial ClientHello/HelloVerify/ClientHello exchange):
==621==by 0x595C555: SSL_accept (ssl_lib.c:940)
==621==by 0x59539F7: dtls1_listen (d1_lib.c:491)
==621==by 0x59533BF: dtls1_ctrl (d1_lib.c:267)
==621==by 0x595CAF2: SSL_ctrl (ssl_lib.c:1106)
==621==by 0x416229: server_ssl_event_cb (server.c:3823)
Either that or something has gone very wrong.
Matt
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Fwd: Re: [openssl.org #3608] SEGV Crash in dtls1_retransmit_message function
Resend this time including r...@openssl.org...sorry for the noise on
openssl-dev...
On 27/11/14 02:54, Praveen Kariyanahalli via RT wrote:
The purpose of DTLSv1_listen is to listen for incoming datagrams from
anyone. If it receives a ClientHello without a cookie it immediately
responds with a HelloVerifyRequest containing a cookie. The client is
expected to respond with a second ClientHello containing the cookie. The
idea is that this is a DoS protection mechanism.
If DTLSv1_listen receives a ClientHello *with* a cookie then it will
return with a positive result. The server is then expected to continue
the handshake with a call to SSL_accept. This is often done in a
separate thread just for that SSL_accept call.
So something like this:
while(1)
{
ssl = SSL_new(ctx);
while(DTLSv1_listen(ssl, client_addr) = 0);
/* client_addr will contain ip address of the client */
Create_a_thread(ssl);
}
In new thread:
SSL_accept(ssl);
[praveen]
Yes we do use the DTLS_listen in the same way, only difference being we are
not doing SSL_accept in a new thread. *Note we are doing it in NON blocking
fashion. *The main DTLSv1_listen responds with HelloVerify. When the next
client hello comes back in, the DTLSv1_listen returns a positive result and
then, we create a new socket and pass on the ssl context to this socket
(*Note:
it is a connected socket, meaning more specific socket*). We create a new
event corresponding to this socket and call the SSL_do_handshake on this
socket. Then we create a new fd less specific for the listening socket
(server socket).
I don't quite understand what you are saying here: we do use the
DTLS_listen in the same way. Are you saying you handle the initial
listen part of the handshake with DTLSv1_listen and then call
SSL_accept on the connected socket? Because this suggests you are
calling DTLSv1_listen a second time (i.e. on a handshake that has
already completed the initial ClientHello/HelloVerify/ClientHello exchange):
==621==by 0x595C555: SSL_accept (ssl_lib.c:940)
==621==by 0x59539F7: dtls1_listen (d1_lib.c:491)
==621==by 0x59533BF: dtls1_ctrl (d1_lib.c:267)
==621==by 0x595CAF2: SSL_ctrl (ssl_lib.c:1106)
==621==by 0x416229: server_ssl_event_cb (server.c:3823)
Either that or something has gone very wrong.
Matt
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[openssl.org #3611] Segmentation fault during SSL_free
On Tue Nov 25 09:38:33 2014, shre...@viptela.com wrote: Version : 1.0.1j Platform : mips64 The client is trying to reach a server that does not exist. And we are trying to free the ssl peer. It has probably tried a retransmission after 1 second and SSL_connect returned ERR_WANT. Any help here is greatly appreciated. Please let me know if you need any more information from the core. This issue is not easily reproducible though. snip state = 4384, This state means we are trying to read a ServerHello which is what we would expect given your description. enc_read_ctx = 0x0, read_hash = 0x12055d840, expand = 0x0, enc_write_ctx = 0x0, write_hash = 0x0, No enc_read_ctx, no enc_write_ctx and no write_hash...but we have a read_hash. That seems wrong. I suspect the data in this location is garbage, hence the crash. I'm guessing some kind of memory corruption going on. Have you tried running this through valgrind? That would be a useful next step. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3569] [PATCH] fix NetWare compilation with branch 1.0.1 / 1.0.2
Applied now. Thanks for the report. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3612] Fwd: [PATCH] Missing documentation for ocsp -timeout option
Patch applied. Many thanks, Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3606] Need RSA_pubkey_digest()
Adding info from Steve on how to do this on one go and reclosing this ticket: On 25/11/14 16:02, Dr. Stephen Henson wrote: I'm curious: I've not seen the private key version before, where is it used? You can actually perform the encode and digest operation all in one go using the ASN1_item_digest function. Something like this should work: rv = ASN1_item_digest(ASN1_ITEM_rptr(RSAPublicKey), mdtype, rsa, md, mdlen); __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Re: [openssl.org #3608] SEGV Crash in dtls1_retransmit_message function
See inline
On Thu, Nov 27, 2014 at 1:36 AM, Matt Caswell via RT r...@openssl.org wrote:
Resend this time including r...@openssl.org...sorry for the noise on
openssl-dev...
On 27/11/14 02:54, Praveen Kariyanahalli via RT wrote:
The purpose of DTLSv1_listen is to listen for incoming datagrams from
anyone. If it receives a ClientHello without a cookie it immediately
responds with a HelloVerifyRequest containing a cookie. The client is
expected to respond with a second ClientHello containing the cookie. The
idea is that this is a DoS protection mechanism.
If DTLSv1_listen receives a ClientHello *with* a cookie then it will
return with a positive result. The server is then expected to continue
the handshake with a call to SSL_accept. This is often done in a
separate thread just for that SSL_accept call.
So something like this:
while(1)
{
ssl = SSL_new(ctx);
while(DTLSv1_listen(ssl, client_addr) = 0);
/* client_addr will contain ip address of the client */
Create_a_thread(ssl);
}
In new thread:
SSL_accept(ssl);
[praveen]
Yes we do use the DTLS_listen in the same way, only difference being we
are
not doing SSL_accept in a new thread. *Note we are doing it in NON
blocking
fashion. *The main DTLSv1_listen responds with HelloVerify. When the next
client hello comes back in, the DTLSv1_listen returns a positive result
and
then, we create a new socket and pass on the ssl context to this socket
(*Note:
it is a connected socket, meaning more specific socket*). We create a
new
event corresponding to this socket and call the SSL_do_handshake on this
socket. Then we create a new fd less specific for the listening socket
(server socket).
[praveen] Here is what I am confused about. The dtls1_listen is calling the
SSL_accept, even in you thread approach this can happen. I don't quite get
what is it you are saying.
*Your approach *
while(1)
{
ssl = SSL_new(ctx);
while(DTLSv1_listen(ssl, client_addr) = 0);
/* client_addr will contain ip address of the client */
Create_a_thread(ssl);
}
*My approach*
global_ssl = SSL_new(ctx);
In Server call back function
ret = DTLSv1_listen(global_ssl, client_addr);
if ret = 0 return;
elsesocket,
bind,
connect (more specific) and
migrate the global_ssl to this peer (peer-ssl) and continue
SSL_do_handshake (NON blocking)
Create new global_ssl = SSL_new(ctx)
Go back to Server call back function
I don't quite understand what you are saying here: we do use the
DTLS_listen in the same way. Are you saying you handle the initial
listen part of the handshake with DTLSv1_listen and then call
SSL_accept on the connected socket? Because this suggests you are
calling DTLSv1_listen a second time (i.e. on a handshake that has
already completed the initial ClientHello/HelloVerify/ClientHello
exchange):
[praveen]
This should *never* be the case. I will put an assert and make sure *THIS*
situation never happens. Before we further discuss the original problem, do
you agree with me so far ?
Regards
-Praveen
==621==by 0x595C555: SSL_accept (ssl_lib.c:940)
==621==by 0x59539F7: dtls1_listen (d1_lib.c:491)
==621==by 0x59533BF: dtls1_ctrl (d1_lib.c:267)
==621==by 0x595CAF2: SSL_ctrl (ssl_lib.c:1106)
==621==by 0x416229: server_ssl_event_cb (server.c:3823)
Either that or something has gone very wrong.
Matt
--
Regards
-Praveen
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: Re: [openssl.org #3608] SEGV Crash in dtls1_retransmit_message function
Just to add to my previous mail.
The peer specific handshake continues in a different event call back
routine. Note: sockets are NON blocking (async handling of events).
On Thu, Nov 27, 2014 at 7:22 AM, Praveen Kariyanahalli prav...@viptela.com
wrote:
See inline
On Thu, Nov 27, 2014 at 1:36 AM, Matt Caswell via RT r...@openssl.org
wrote:
Resend this time including r...@openssl.org...sorry for the noise on
openssl-dev...
On 27/11/14 02:54, Praveen Kariyanahalli via RT wrote:
The purpose of DTLSv1_listen is to listen for incoming datagrams from
anyone. If it receives a ClientHello without a cookie it immediately
responds with a HelloVerifyRequest containing a cookie. The client is
expected to respond with a second ClientHello containing the cookie.
The
idea is that this is a DoS protection mechanism.
If DTLSv1_listen receives a ClientHello *with* a cookie then it will
return with a positive result. The server is then expected to continue
the handshake with a call to SSL_accept. This is often done in a
separate thread just for that SSL_accept call.
So something like this:
while(1)
{
ssl = SSL_new(ctx);
while(DTLSv1_listen(ssl, client_addr) = 0);
/* client_addr will contain ip address of the client */
Create_a_thread(ssl);
}
In new thread:
SSL_accept(ssl);
[praveen]
Yes we do use the DTLS_listen in the same way, only difference being we
are
not doing SSL_accept in a new thread. *Note we are doing it in NON
blocking
fashion. *The main DTLSv1_listen responds with HelloVerify. When the
next
client hello comes back in, the DTLSv1_listen returns a positive result
and
then, we create a new socket and pass on the ssl context to this socket
(*Note:
it is a connected socket, meaning more specific socket*). We create a
new
event corresponding to this socket and call the SSL_do_handshake on this
socket. Then we create a new fd less specific for the listening socket
(server socket).
[praveen] Here is what I am confused about. The dtls1_listen is calling
the SSL_accept, even in you thread approach this can happen. I don't quite
get what is it you are saying.
*Your approach *
while(1)
{
ssl = SSL_new(ctx);
while(DTLSv1_listen(ssl, client_addr) = 0);
/* client_addr will contain ip address of the client */
Create_a_thread(ssl);
}
*My approach*
global_ssl = SSL_new(ctx);
In Server call back function
ret = DTLSv1_listen(global_ssl, client_addr);
if ret = 0 return;
elsesocket,
bind,
connect (more specific) and
migrate the global_ssl to this peer (peer-ssl) and
continue SSL_do_handshake (NON blocking)
Create new global_ssl = SSL_new(ctx)
Go back to Server call back function
I don't quite understand what you are saying here: we do use the
DTLS_listen in the same way. Are you saying you handle the initial
listen part of the handshake with DTLSv1_listen and then call
SSL_accept on the connected socket? Because this suggests you are
calling DTLSv1_listen a second time (i.e. on a handshake that has
already completed the initial ClientHello/HelloVerify/ClientHello
exchange):
[praveen]
This should *never* be the case. I will put an assert and make sure *THIS*
situation never happens. Before we further discuss the original problem, do
you agree with me so far ?
Regards
-Praveen
==621==by 0x595C555: SSL_accept (ssl_lib.c:940)
==621==by 0x59539F7: dtls1_listen (d1_lib.c:491)
==621==by 0x59533BF: dtls1_ctrl (d1_lib.c:267)
==621==by 0x595CAF2: SSL_ctrl (ssl_lib.c:1106)
==621==by 0x416229: server_ssl_event_cb (server.c:3823)
Either that or something has gone very wrong.
Matt
--
Regards
-Praveen
--
Regards
-Praveen
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[openssl.org #3608] SEGV Crash in dtls1_retransmit_message function
On Thu Nov 27 16:23:04 2014, prav...@viptela.com wrote: *My approach* global_ssl = SSL_new(ctx); In Server call back function ret = DTLSv1_listen(global_ssl, client_addr); if ret = 0 return; else socket, bind, connect (more specific) and migrate the global_ssl to this peer (peer-ssl) and continue SSL_do_handshake (NON blocking) Create new global_ssl = SSL_new(ctx) Go back to Server call back function Ahhh, ok. I understand your approach now. Yes. This should be ok. I don't quite understand what you are saying here: we do use the DTLS_listen in the same way. Are you saying you handle the initial listen part of the handshake with DTLSv1_listen and then call SSL_accept on the connected socket? Because this suggests you are calling DTLSv1_listen a second time (i.e. on a handshake that has already completed the initial ClientHello/HelloVerify/ClientHello exchange): [praveen] This should *never* be the case. I will put an assert and make sure *THIS* situation never happens. Before we further discuss the original problem, do you agree with me so far ? Yes, please do that - and I think we are in agreement. What concerns me is that the valgrind logs show a message being sent from DTLSv1_listen which should never be sent whilst listening. That means either: 1) There's a bug in your code that means you are re-entering DTLSv1_listen when you shouldn't be or 2) There's a bug in our code that means we are not correctly handling the listening state I'd like to figure out which of 1 or 2 is correct! Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3608] SEGV Crash in dtls1_retransmit_message function
Thanks Matt. Will keep you posted on 1. Coming back to the original crash. Here is some update. Our server started seeing the crash and leaks, after our negative stress testing suite added some pmtu testcases. i.e., during 1000s of connections the underlying mtu(s) were changed (very low - to high) randomly and frequently. Once we reduced the frequency the server held up. Does that give u some clue ? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3560] OpenSSL selects weak digest for (EC)DH kex signing in TLSv1.2 when connecting to SNI virtual server
Fixed now, thanks for the report. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3613] Patch: Fix warning in Nginx logs on every connect when GOST TLS used.
Thanks for the report. I have applied a fix in git...a slightly different solution to the one proposed in your patch. Thanks Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #1767] bug of EVP_Cipher when use openssl engine
Thanks for the report. This has now been fixed. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3559] Weak digest for (EC)DH key exchange when connecting to SNI defined host
Steve has now fixed this. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3556] Problem building openssl 1.0.1i in debug mode
Closing this ticket as Andy has provided an answer. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3510] Clang warning/error fixes
Mike withdrew this ticket so closing. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3315] Why does the linker complain about undefined symbols?
No further information supplied in response to Kurt's request, so closing this ticket. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3228] Bug report: openssl 1.0.1f build fails with make: invalid option
Fixed some while ago as part of fixing ticket 3253. Closing this ticket. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3180] Brainpool Elliptic Curves in OpenSSL version 1.0.2 - Re: #2239: [PATCH] RFC 5639 support
Not a bug. If there are still issues please direct questions to the openssl-users list. Closing this ticket. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3086] Re: OpenSSL
It is unclear what the issue is here. If you are still having problems then please send an email to openssl-users. Closing this ticket. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3225] make 'failure'
Insufficient information to recreate. If this is still a problem then please reopen this ticket. Closing. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3115] s3_srvr.c out-of-bound dereference (minor bug)
Thanks for the report. This was fixed some while ago as a result of ticket 3244. Closing. Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
