Re: [PATCH] Support DTLS compatibility with DTLS1_BAD_VER client
Hi Ghennadi, Thanks for your effort, but I'm not sure about the benefits of this patch. As far as I know DTLS1_BAD_VER is only a hack to support Cisco's AnyConnect VPN servers, and it's not backed by the DTLS specification. Is Cisco still using the wrong version or did they fix that? Is there any other software that also uses DTLS1_BAD_VER? Why would running a server supporting DTLS1_BAD_VER be desirable? My main concerns are that it's not supported by the DTLS specification and should therefore not be used at all, and there are so many considerations in the code for DTLS1_BAD_VER already. Best regards Robin On Jun 28, 2012, at 9:45 AM, Ghennadi Procopciuc wrote: Hello All, We observed that the current implementation contains a client that can communicate with a DTLS1_BAD_VER server but does not contains the server that can communicate with a DTLS1_BAD_VER client, so we wrote a patch that enables OpenSSL to negotiate DTLS1_BAD_VER with itself. Changes (all in [d1_srvr.c] ) : 1. The server accepts a ClientHello from a client that uses DTLS1_BAD_VER. 2. The server responds to a client that uses DTLS1_BAD_VER. 3. Disable sending TLS extensions to DTLS1_BAD_VER clients. Is there interest in this patch ? Thanks, Ghennadi dtls1_bad_ver-server.patch __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2844] TLS 1.2 server sends abort when TLS 1.2 client doesn't include Signature Algorithm extension
Confirmed. The problem is resolved in the latest snapshot. Thank you. On 07/06/2012 04:57 PM, Stephen Henson via RT wrote: [fol...@cisco.com - Fri Jul 06 17:50:15 2012]: RFC 5246 allows a TLS 1.2 client to omit the Signature Algorithm extension. See section 7.4.1.4.1 for details. This creates a problem for OpenSSL 1.0.1 when acting as a server and either a DSA or ECDSA certificate is used. Because the ClientHello does not contain the Signature Algorithm extension, tls1_process_sigalgs() is never invoked on the server side to set the digest used for the session context. Later during the handshake when the server sends the ServerKeyExchange, the call to tls12_get_sigandhash() fails, which causes the server to abort the handshake. The attached patch to tls12_get_sigandhash() resolves the problem. However, the OpenSSL maintainers may have a better solution. Have you tried a recent 1.0.1 snapshot? I came across the same issue when developing more configurable supported signature algorithms support. The fix I made was: http://cvs.openssl.org/chngview?cn=22655 Steve. attachment: foleyj.vcf
Re: [openssl.org #2844] TLS 1.2 server sends abort when TLS 1.2 client doesn't include Signature Algorithm extension
Confirmed. The problem is resolved in the latest snapshot. Thank you. On 07/06/2012 04:57 PM, Stephen Henson via RT wrote: [fol...@cisco.com - Fri Jul 06 17:50:15 2012]: RFC 5246 allows a TLS 1.2 client to omit the Signature Algorithm extension. See section 7.4.1.4.1 for details. This creates a problem for OpenSSL 1.0.1 when acting as a server and either a DSA or ECDSA certificate is used. Because the ClientHello does not contain the Signature Algorithm extension, tls1_process_sigalgs() is never invoked on the server side to set the digest used for the session context. Later during the handshake when the server sends the ServerKeyExchange, the call to tls12_get_sigandhash() fails, which causes the server to abort the handshake. The attached patch to tls12_get_sigandhash() resolves the problem. However, the OpenSSL maintainers may have a better solution. Have you tried a recent 1.0.1 snapshot? I came across the same issue when developing more configurable supported signature algorithms support. The fix I made was: http://cvs.openssl.org/chngview?cn=22655 Steve. inline: foleyj.vcf
FIPS Object Module 2.0 - Compliance with 186-3
According to the NIST web site, the 2.0 FIPS Object Module claims compliance for FIPS 186-3 using the Extra Random Bits method for EC public key generation. This is taken from: http://csrc.nist.gov/groups/STM/cavp/documents/dss/ecdsaval.html#270 The extra random bits method is defined in FIPS 186-3 Appendix B.4.1. After inspecting EC_KEY_generate_key(), it's not clear how the requirements in appendix B.4.1 have been met. The following code from EC_KEY_generate_key() appears to be used to generate a random number to be used as the private key. do if (!BN_rand_range(priv_key, order)) goto err; while (BN_is_zero(priv_key)); Can someone explain how this complies with appendix B.4.1, which states an additional 64 bits of random data should be generated when deriving the key? Thank you. attachment: foleyj.vcf
