Re: [openssl-users] Crash in SSL_do_handshake: s->method->ssl_renegotiate_check(s)

2015-04-04 Thread Michael Clark
On 5/4/15 11:11 am, Jeffrey Walton wrote:
> On Sat, Apr 4, 2015 at 11:03 PM, Michael Clark  
> wrote:
>> ...
>> Now works on Darwin/OSX: https://github.com/michaeljclark/async_tls_test
>>
>> Just working through poll peculiarities on Linux. Thanks.
> Related: libevent (http://libevent.org/) does a pretty good job of
> abstracting that away. I believe it works on Linux, BSDs, OS X and
> Windows. But you'll have to switch to a fully asynchronous
> architecture.

Thanks. Yes there is ASIO too:

  https://think-async.com/Asio/AsioStandalone
 
http://stackoverflow.com/questions/18506739/boostasio-http-server-extremely-slow

I've looked at libevent. There is also libev and libuv. I think they may
use the BIO method for async operation, which doesn't share fds with
openssl; only memory buffers. The BIO approach may require additional
buffer copies. Extra buffer copies may be negligible compared to the
encryption overhead, however AES-NI is very fast in terms of cycles per
byte.

With connection establishment excluded (a large chunk of the TLS
overhead) and the case of 16 parallel keepalive connections pumping
objects to/from the server (to/from RAM or SSD); the overhead might be
appreciable. I am able to get about 18GB/sec AES encryption with AES-NI
on a 6-core/12-thread machine with openssl AES-NI. That is a substantial
proportion of the memory bandwidth of the machine which is approximately
~60GB/sec. I guess buffer copies will happen in L2/L3 cache where the
bandwidth is higher, so perhaps this is less of an issue.

In any case I was thinking of using the SSL_ERROR_WANT_READ /
SSL_ERROR_WANT_WRITE approach vs the BIO approach. Exploring this at the
moment...

I'm a beggar for punishment and I like to be aware of the quirks at the
foundations and have written my own event abstraction layer that uses
poll, kqueue and epoll. It doesn't handle TLS *yet*. I wanted to
implement a simple poll-based echo server to get the hang of the OpenSSL
API.

https://github.com/metaparadigm/latypus
https://github.com/metaparadigm/latypus/blob/master/src/pollset.h

With plain HTTP latypus can do ~255,000 reqs/sec (16 threads) vs nginx
~140,000 req/sec (16 processes), logging enabled, on a 16 core AWS
r3.4xlarge instance. This is mainly due to a more efficient logging
implementation (in memory async ring buffer). latypus is slower than
nginx with logging disabled but it does not have an open file cache. I
would also like to instrument the server to log TLS options, ciphers and
versions. Something most current generation servers do not do. For this
I need to be comfortable with the OpenSSL API. Hence the simple async
echo server.

Also want to use C++1y vs C, and use existing language infrastructure
where possible e.g. std::set, std::map, std::vector, etc

Many of the current C engines reinvent their own hash tables, lists and
buffers. i.e. there are as many hash table implementations as there are
servers.

~mc
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] Crash in SSL_do_handshake: s->method->ssl_renegotiate_check(s)

2015-04-04 Thread Michael Clark
On 5/4/15 7:35 am, Michael Clark wrote:
> On 5/4/15 7:32 am, Graham Leggett wrote:
>> On 04 Apr 2015, at 9:46 PM, Michael Clark  wrote:
>>
>>> I am having an issue where the server crashes on subsequent connections
>>> *if* I close the connection file descriptor. See the note in
>>> openssl_async_echo_server.cc on line 239. If I leak a file descriptor
>>> and the next connection uses a new fd then the server works fine. Does
>>> openssl have an internal map of file descriptors? Am I freeing the
>>> connection correctly?
>> In the past when I have built async SSL code, I’ve used memory pools from 
>> the Apache Portable runtime (APR) to make sure that all the created 
>> resources get properly cleaned up when connections are closed.
>>
>> You need to make sure everything you create is properly released when done. 
>> If you don’t, you either leak or crash.
>>
> Yes however this is a case where I am closing the fd, and calling
> SSL_free on the ssl object. i.e. cleaning up, then I get the crash. When
> I leak the fd, it works fine.
>
> Note this is on OS X. Just discovered I am not getting POLLHUP on Linux,
> rather POLLIN and read returning 0.
>
> Still debugging...

Apologies all. It wasn't a TLS bug rather I had neglected to remove a
connection from an fd->connection map.

Now works on Darwin/OSX: https://github.com/michaeljclark/async_tls_test

Just working through poll peculiarities on Linux. Thanks.

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] Crash in SSL_do_handshake: s->method->ssl_renegotiate_check(s)

2015-04-04 Thread Michael Clark
On 5/4/15 7:32 am, Graham Leggett wrote:
> On 04 Apr 2015, at 9:46 PM, Michael Clark  wrote:
>
>> I am having an issue where the server crashes on subsequent connections
>> *if* I close the connection file descriptor. See the note in
>> openssl_async_echo_server.cc on line 239. If I leak a file descriptor
>> and the next connection uses a new fd then the server works fine. Does
>> openssl have an internal map of file descriptors? Am I freeing the
>> connection correctly?
> In the past when I have built async SSL code, I’ve used memory pools from the 
> Apache Portable runtime (APR) to make sure that all the created resources get 
> properly cleaned up when connections are closed.
>
> You need to make sure everything you create is properly released when done. 
> If you don’t, you either leak or crash.
>
Yes however this is a case where I am closing the fd, and calling
SSL_free on the ssl object. i.e. cleaning up, then I get the crash. When
I leak the fd, it works fine.

Note this is on OS X. Just discovered I am not getting POLLHUP on Linux,
rather POLLIN and read returning 0.

Still debugging...

~mc
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] Crash in SSL_do_handshake: s->method->ssl_renegotiate_check(s)

2015-04-04 Thread Michael Clark
On 5/4/15 3:46 am, Michael Clark wrote:
>   SSL_free(ssl_conn.ssl);
>   // TODO - crashes on subsequent connections in SSL_do_handshake if we
> close the fd.
>   //   
> ssl_lib.c::SSL_do_handshake::s->method->ssl_renegotiate_check(s);
>   //Why? reuse of same fd number for subsequent connection?
>   //comment the following line and the server works but leaks fds
>   close(ssl_conn.conn_fd);

This is what is happening:

http://i.imgur.com/6R6sg4L.png

For some reason s->s3 is NULL and ssl3_renegotiate_check is called.

The code (*1) is using TLSv1_server_method()

~mc

[1] https://github.com/michaeljclark/async_tls_test
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


[openssl-users] Crash in SSL_do_handshake: s->method->ssl_renegotiate_check(s)

2015-04-04 Thread Michael Clark
Hi,

I am trying to write the simplest possible example of an async TLS
client and server using non-blocking IO and
SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE events. The main purpose is to
test the async IO code paths with a). an absence of all of the complex
options in s_client and s_server, and b). self-contained source that is
easy to read.

I am having an issue where the server crashes on subsequent connections
*if* I close the connection file descriptor. See the note in
openssl_async_echo_server.cc on line 239. If I leak a file descriptor
and the next connection uses a new fd then the server works fine. Does
openssl have an internal map of file descriptors? Am I freeing the
connection correctly?

  SSL_free(ssl_conn.ssl);
  // TODO - crashes on subsequent connections in SSL_do_handshake if we
close the fd.
  //   
ssl_lib.c::SSL_do_handshake::s->method->ssl_renegotiate_check(s);
  //Why? reuse of same fd number for subsequent connection?
  //comment the following line and the server works but leaks fds
  close(ssl_conn.conn_fd);

Here is the code:

 
https://github.com/michaeljclark/async_tls_test/blob/master/src/openssl_async_echo_server.cc
 
https://github.com/michaeljclark/async_tls_test/blob/master/src/openssl_async_echo_client.cc

Both files are standalone with no dependencies (one of the goals) and
can be compiled as so:

  clang++ -std=c++11 openssl_async_echo_client.cc -lcrypto -lssl -o
openssl_async_echo_client
  clang++ -std=c++11 openssl_async_echo_server.cc -lcrypto -lssl -o
openssl_async_echo_server

or alternatively they can be built using the Makefile in the git repo
which contains all dependencies beside openssl e.g. demo cert.pem,
key.pem and cacert.pem:

  https://github.com/michaeljclark/async_tls_test/

e.g.

  git clone https://github.com/michaeljclark/async_tls_test.git
  cd async_tls_test
  make

I would appreciate if anyone could help me out. It may well be a bug in
my demo code or it could be a bug in openssl.

I've used a smattering of C++1y where it simplifies the code (connection
hash table, poll descriptor management) but it is mostly plain C.

A simple example of a *working* async openssl client and server would be
quite useful...

Michael.

___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users