> [n...@gnutls.org - Sat Mar 17 14:57:31 2012]: > > Hello, > My reading of RFC4492 is that the ECC ciphersuites apply only to TLS > 1.0 or later. According to it: "This document describes additions to TLS > to support ECC, applicable both to TLS Version 1.0 [2] and to TLS > Version 1.1 [3]. In particular, it defines...". > > So it seems that SSL 3.0 shouldn't be negotiated with these > ciphersuites. However it seems that openssl s_server negotiates > ECC ciphersuites even under SSL 3.0. > > For example: > $ openssl version > OpenSSL 1.0.0h 12 Mar 2012 > > $ openssl s_server -cert x509/cert-rsa.pem -key x509/key-rsa.pem -port 5556 > Using default temp DH parameters > Using default temp ECDH parameters > ACCEPT > > $ ./gnutls-cli localhost -p 5556 --x509cafile > ../doc/credentials/x509/ca.pem -d 99 > ... > |<3>| HSK[0x1d0bdc0]: Server's version: 3.0 > ... > |<2>| unsupported cipher suite C0.13 > ... > *** Handshake has failed > GnuTLS error: Could not negotiate a supported cipher suite. > > So it seems that gnutls rejected the connection because the ciphersuite > isn't valid for this TLS version. > > [*] The credentials are just an RSA CA certificate and an RSA server > certificate. >
The EC codes does need a bit of revising, that is one of its many quirks. I'm trying to work out though how that client ends up producing that condition. The only way I can think s_server with those command line options could end up using SSL v3.0 is if the client sent a v3.0 client hello. That would mean that it was sending a list of supported ciphers including some it wasn't willing to support... not something you'd expect to see in practice. 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
