Re: [openssl-users] [openssl-dev] removing compression?
On Fri, Apr 03, 2015 at 07:53:59PM +, Salz, Rich wrote: And the best practice these days is to do it at the application layer, and feed the compressed bytes down to TLS. The BREACH attack makes use of that. Kurt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] removing compression?
On 03.04.15 21:53, Salz, Rich wrote: But on a larger scale, does anyone use TLS compression? It has certainly caused problems with HTTP (see http://en.wikipedia.org/wiki/CRIME). And the best practice these days is to do it at the application layer, and feed the compressed bytes down to TLS. How about at least implementing the length hiding mitigation suggested by the BREACH paper http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf by randomly interspersing flush commands into the data stream (description and example implementation https://github.com/wnyc/breach_buster)? It's not perfect but for some use cases better than having no compression at all. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] removing compression?
On Fri, Apr 03, 2015 at 07:53:59PM +, Salz, Rich wrote: I am thinking about removing compression and would like to know what the community thinks. At the very least drop zlib-dynamic support. This has caused DLL-hell on some platforms, when a dynamically loaded libz conflicts with a different statically compiled libz in another library. For example, some ports versions of FreeBSD Postfix with OpenSSL and MySQL crash in SSL_accept when compression is negotiated (because MySQL includes an internal libz in those builds). My own builds of OpenSSL have always (over a decade now) been no-zlib. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Fwd to openssl-users Re: [openssl-dev] Why the issuer cannot be found?
On Sat, Apr 04, 2015 at 05:31:37AM +0200, Jakob Bohm wrote: (top posting like the rest of the thread) What makes you think it is incorrect to check the Key Identifier (where present) before checking a signature against a key? What other reasonable purpose could the Key Identifier fields serve? Indeed I have code that relies on OpenSSL taking the SKI and AKI into account. -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] removing compression?
by randomly interspersing flush commands into the data stream (description and example implementation https://github.com/wnyc/breach_buster)? It's not perfect but for some use cases better than having no compression at all. Flushing the stream seems like an application-level thing to do, and not something openssl generally does. It might be better than having no compression at all, the question is do we need compression in openssl at all? :) ___ 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)
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 mich...@metaparadigm.com 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)
On Sat, Apr 4, 2015 at 11:03 PM, Michael Clark mich...@metaparadigm.com 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. Jeff ___ 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)
On 5/4/15 11:11 am, Jeffrey Walton wrote: On Sat, Apr 4, 2015 at 11:03 PM, Michael Clark mich...@metaparadigm.com 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
[openssl-users] A question to the VMS folks out there (SSL_TASK)
Hi, this is a question to the VMS folks out there. A few days ago, I took SSL_TASK out of the OpenSSL master branch (that is, the files crypto/bio/bss_rtcp.c and ssl/ssl_task.c). It never really belonged in OpenSSL but stayed there for reasons only historians can tell at this point. I'm currently having a hg repo with the files as part of the vms-ports effort (https://sourceforge.net/p/vms-ports/ssl_task/), but I'm starting to wonder if anyone is still using this stuff or if it's just dead code by now. The answer will make all the difference to my willingness to keep this code alive or not. Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish ___ 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)
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
Re: [openssl-users] Fwd to openssl-users Re: [openssl-dev] Why the issuer cannot be found?
In fact I did not use any store (thus openssl should be correct). I just
tested the logic (openssl verify -CAfile $ca_file $file) and found that it
is a little tricky to find the issuer of a certificate (e.g.,
name/sn-based, key id based), and the behavior is unpredictable. Sometimes
a certificate may have two or more authority key ids (it should be
incorrect, but I just produced some certificates to test the logic, and
found that the issuer can be found or not found.)
Sounds like that the issuer cannot be found because the authority key id of
file3.pem does not match with the subject key id of file4.pem. Meanwhile
the building strategy is flexible. I also made some certificates contains
two or more instances of authority key ids, and the issuer can be found (or
sometimes cannot be found).
On Sat, Apr 4, 2015 at 2:35 PM, Yuting Chen che...@cs.sjtu.edu.cn wrote:
In fact I did not use any store (thus openssl should be correct). I just
tested the logic (openssl verify -CAfile $ca_file $file) and found that it
is a little tricky to find the issuer of a certificate (e.g.,
name/sn-based, key id based), and the behavior is unpredictable. Sometimes
a certificate may have two or more authority key ids (it should be
incorrect, but I just produced some certificates to test the logic, and
found that the issuer can be found or not found.)
Sounds like that the issuer cannot be found because the authority key id
of file3.pem does not match with the subject key id of file4.pem. Meanwhile
the building strategy is flexible. I also made some certificates contains
two or more instances of authority key ids, and the issuer can be found (or
sometimes cannot be found).
On Sat, Apr 4, 2015 at 1:22 PM, Jeffrey Walton noloa...@gmail.com wrote:
What makes you think it is incorrect to check the Key
Identifier (where present) before checking a signature
against a key?
An X.509 certificate does one thing: it binds a public key to an
identity. In PKI, a public key alone means nothing because trust is
placed in principals or issuers.
In end entity certificate, you don't need the Issuer DN and AKI
because they are disjoint and uncertified. You need the issuing
certificate with a valid signature. But it would be helpful to find
the issuer's certificate easily.
If the AKI is missing, wrong or a duplicate, then it just means that
you lost the ability to find an issuing certificate easily.
OpenSSL could be more flexible or friendly in its building strategy.
But that could move into the which directory problem rather quickly.
If Yuting Chen provided a store with the required certificates, then
OpenSSL is probably incorrect. Chen's original email does not detail
it, so its hard to say at the moment.
What other reasonable purpose could the Key Identifier
fields serve?
Its a hint to help find the issuing certificate. Its supposed to be
used when an issuer has multiple signing keys.
The AKI does not need to be a key identifier. It can also be be the {
Issuer DN, Serial Number } pair of the issuer's certificate.
Jeff
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] removing compression?
On Fri, Apr 3, 2015 at 3:53 PM, Salz, Rich rs...@akamai.com wrote: I am thinking about removing compression and would like to know what the community thinks. What the community thinks does not matter. If your threat model includes recovery via compression through protocols like TLS, HTTPS and SPDY, then you have to disable it. Or if you have a defensive security posture, then you should disable it. You can disable it in TLS by configuring OpenSSL with no-comp: ./configure no-ssl2 no-ssl3 no-com --prefix=/usr/local For what its worth, I've been disabling compression since the attacks surfaced. I've never had a problem. Jeff ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Fwd to openssl-users Re: [openssl-dev] Why the issuer cannot be found?
OpenSSL could be more flexible or friendly in its building strategy. But that could move into the which directory problem rather quickly. This is kind of interesting. Looking at RFC 5280, section 4.2.1.1 Authority Key Identifier (p. 26): The value of the keyIdentifier field SHOULD be derived from the public key used to verify the certificate's signature or a method that generates unique values. So there's no requirement that the digest of the signer's public key be used in the subject's AKI. It looks like it could be a totally random value. The only requirement is that its unique. Now this is odd or at least counter-intuitive: the standard does not require that Authority Key Identifier in the subject certificate actually match the Subject Key Identifier in the signer. Its not stated and labeled MUST; in fact, it does not appear to be stated. I'm looking at sections 4.2.1.1 Authority Key Identifier and 4.2.1.2 Subject Key Identifier (maybe its stated elsewhere). If I am reading things correctly: I think that means OpenSSL is incorrect if its rejecting a valid path that could be constructed. I have to be careful how I say this since it depends on OpenSSL having the required certificates to construct the path (among other things). But a mismatched AKI is *not* a reason to reject. Jeff ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Fwd to openssl-users Re: [openssl-dev] Why the issuer cannot be found?
What makes you think it is incorrect to check the Key
Identifier (where present) before checking a signature
against a key?
An X.509 certificate does one thing: it binds a public key to an
identity. In PKI, a public key alone means nothing because trust is
placed in principals or issuers.
In end entity certificate, you don't need the Issuer DN and AKI
because they are disjoint and uncertified. You need the issuing
certificate with a valid signature. But it would be helpful to find
the issuer's certificate easily.
If the AKI is missing, wrong or a duplicate, then it just means that
you lost the ability to find an issuing certificate easily.
OpenSSL could be more flexible or friendly in its building strategy.
But that could move into the which directory problem rather quickly.
If Yuting Chen provided a store with the required certificates, then
OpenSSL is probably incorrect. Chen's original email does not detail
it, so its hard to say at the moment.
What other reasonable purpose could the Key Identifier
fields serve?
Its a hint to help find the issuing certificate. Its supposed to be
used when an issuer has multiple signing keys.
The AKI does not need to be a key identifier. It can also be be the {
Issuer DN, Serial Number } pair of the issuer's certificate.
Jeff
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] removing compression?
On Sat, Apr 4, 2015 at 11:15 AM, Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Fri, Apr 03, 2015 at 07:53:59PM +, Salz, Rich wrote: My own builds of OpenSSL have always (over a decade now) been no-zlib. That's kind of interesting (to me). Did you disable it because you were suspicious of compression leaking information? Or did you disable it because of dll hell issues? ___ 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)
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
Re: [openssl-users] Crash in SSL_do_handshake: s-method-ssl_renegotiate_check(s)
On 04 Apr 2015, at 9:46 PM, Michael Clark mich...@metaparadigm.com 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. Regards, Graham — ___ 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)
On 5/4/15 7:32 am, Graham Leggett wrote: On 04 Apr 2015, at 9:46 PM, Michael Clark mich...@metaparadigm.com 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] Modulus field in text display of a certificate
Modulus: 00:9a:18:ca:4b:94:0d:00:2d:af:03:29:8a:f0:0f: The leading zero is so that you don't confuse it with a sign bit. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
