Re: handshake failure with OPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50
On Nov 22, 2012, at 13:29 , Dr. Stephen Henson st...@openssl.org wrote: So you're saying it does *NOT* set SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS? That should be OK then as inserting empty fragments is one way of preventing the BEAST attack but some servers can't handle it. That's correct, curl does NOT set this option. However, that does not appear to be a problem here, since all 12 failing servers I've found fail in the same manner with both curl and the openssl command line client. Rainer __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: handshake failure with OPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50
On Nov 20, 2012, at 12:47 , Dr. Stephen Henson st...@openssl.org wrote: On Tue, Nov 20, 2012, Dr. Stephen Henson wrote: On Fri, Nov 16, 2012, Rainer Canavan wrote: Since openssl is part of a product that we ship, would you consider moving RC4-MD5 to the front of the cipher list by default a good idea, or are there drawbacks that I overlooked, or would this even be preferred, since RC4 has been propagated as a mitigating method for the so called BEAST attack? Whether BEAST is a problem or not depends on your product. I believe (someone correct me if I'm wrong) that for BEAST to work an attacker needs to be able to adaptively inject plaintext which then gets encrypted using the session parameters. If there is no mechanism to do that in your product you aren't vulnerable to BEAST at all so using AES in CBC mode is fine. It is possible that our customers use our product in a way that permits plaintext injection (e.g. javascript into am HTTP response transmitted over open WiFi networks). Just to clarify that: your description implies your product is an SSL/TLS client which can connect to various servers. Do you need to set SSL_OP_ALL in your product? We're using lib curl for the client bit of our products, and that already sets SSL_OP_ALL (minus SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG, SSL_OP_NO_TICKET and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS). I've just tested openssl 1.0.1c and 0.9.8x with various options (-DOPENSSL_NO_TLS1_2_CLIENT -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50, modified cipher order) on all 128 SSL Servers I could find in our logs from yesterday. It turns out that all work flawlessly with openssl 0.9.8, and 12 don't work with 1.0.1c for some combination of those options. Since at most 2 or 3 of the 12 servers work with any combination of the options and different subsets work or fail depending on the options, I've concluded that this is a fruitless endeavour, and our users will just have to manually force SSLv3 or TLSv1 for the affected servers (which works for 100% of the servers even with 1.0.1c). regards, rainer__ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: handshake failure with OPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50
On Tue, Nov 20, 2012, Rainer Canavan wrote: On Nov 20, 2012, at 12:47 , Dr. Stephen Henson st...@openssl.org wrote: On Tue, Nov 20, 2012, Dr. Stephen Henson wrote: On Fri, Nov 16, 2012, Rainer Canavan wrote: Since openssl is part of a product that we ship, would you consider moving RC4-MD5 to the front of the cipher list by default a good idea, or are there drawbacks that I overlooked, or would this even be preferred, since RC4 has been propagated as a mitigating method for the so called BEAST attack? Whether BEAST is a problem or not depends on your product. I believe (someone correct me if I'm wrong) that for BEAST to work an attacker needs to be able to adaptively inject plaintext which then gets encrypted using the session parameters. If there is no mechanism to do that in your product you aren't vulnerable to BEAST at all so using AES in CBC mode is fine. It is possible that our customers use our product in a way that permits plaintext injection (e.g. javascript into am HTTP response transmitted over open WiFi networks). Just to clarify that: your description implies your product is an SSL/TLS client which can connect to various servers. Do you need to set SSL_OP_ALL in your product? We're using lib curl for the client bit of our products, and that already sets SSL_OP_ALL (minus SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG, SSL_OP_NO_TICKET and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS). So you're saying it does *NOT* set SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS? That should be OK then as inserting empty fragments is one way of preventing the BEAST attack but some servers can't handle it. 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
Re: handshake failure with OPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50
On Nov 15, 2012, at 18:04 , Dr. Stephen Henson st...@openssl.org wrote: The -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH option was a quick hack to workaround some broken servers. It may not be needed now many have been fixed and applications where you have some control over the connection parameters don't really need it at all. So far, we have encountered a handful of servers that are still broken, while the server referenced in my previous mail was the first one that failed with MAX_TLS1_2_CIPHER_LENGTH. It might be that there are no supported ciphersuites in the truncated list: try messing around with the ciphers and disable (for example) ECDH. For example DEFAULT:!ECDH The server in question actually supports only RC4-MD5 AES128-SHA, both of which get cut off. Rearranging the Ciphers with e.g. RC4-MD5:DEFAULT fixes this. Since openssl is part of a product that we ship, would you consider moving RC4-MD5 to the front of the cipher list by default a good idea, or are there drawbacks that I overlooked, or would this even be preferred, since RC4 has been propagated as a mitigating method for the so called BEAST attack? regards, rainer__ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: handshake failure with OPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50
On Fri, Nov 16, 2012, Rainer Canavan wrote: Since openssl is part of a product that we ship, would you consider moving RC4-MD5 to the front of the cipher list by default a good idea, or are there drawbacks that I overlooked, or would this even be preferred, since RC4 has been propagated as a mitigating method for the so called BEAST attack? Whether BEAST is a problem or not depends on your product. I believe (someone correct me if I'm wrong) that for BEAST to work an attacker needs to be able to adaptively inject plaintext which then gets encrypted using the session parameters. If there is no mechanism to do that in your product you aren't vulnerable to BEAST at all so using AES in CBC mode is fine. 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
Re: handshake failure with OPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50
On Tue, Nov 20, 2012, Dr. Stephen Henson wrote: On Fri, Nov 16, 2012, Rainer Canavan wrote: Since openssl is part of a product that we ship, would you consider moving RC4-MD5 to the front of the cipher list by default a good idea, or are there drawbacks that I overlooked, or would this even be preferred, since RC4 has been propagated as a mitigating method for the so called BEAST attack? Whether BEAST is a problem or not depends on your product. I believe (someone correct me if I'm wrong) that for BEAST to work an attacker needs to be able to adaptively inject plaintext which then gets encrypted using the session parameters. If there is no mechanism to do that in your product you aren't vulnerable to BEAST at all so using AES in CBC mode is fine. Just to clarify that: your description implies your product is an SSL/TLS client which can connect to various servers. Do you need to set SSL_OP_ALL in your product? 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
Re: handshake failure with OPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50
On Wed, Nov 14, 2012, Rainer Canavan wrote: We compile our application with -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50 to avoid the server hang described in the Changelog for 1.0.1a. However, I have now encountered a server that fails to handshake with openssl (the command line tool or e.g. curl linked against libopenssl) if openssl has been built with -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50 Building without this option (or values =124) or forcing sslv3 or tlsv1 works even with this server, independent of the CIPHER_LENGTH option. Is it possible to work around this in openssl, or is this an bug or configuration problem of the server? The -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH option was a quick hack to workaround some broken servers. It may not be needed now many have been fixed and applications where you have some control over the connection parameters don't really need it at all. It might be that there are no supported ciphersuites in the truncated list: try messing around with the ciphers and disable (for example) ECDH. For example DEFAULT:!ECDH 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
