On Sunday 05 February 2017 11:13:16 Andreas Bartelt wrote: > On 02/05/17 07:41, Joel Sing wrote: > > You can just specify X25519 as a group - it will not appear in `openssl > > ecparam -list_curves' since it is not a standard EC curve. > > thanks - I didn't notice that capitalization is important here. Maybe > x25519 and ecdh_x25519 [IANA] should also be accepted as valid names > [http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml].
I'll consider this, however all of the RFCs refer to it as X25519 (e.g. RFC7748 and draft-ietf-curdle-pkix-03). This is also no different to the fact that you cannot use 'Prime256v1' or 'p-384'. > The definition of the curve itself is provided in RFC 7748 - RFCs for > some other listed curves (e.g., brainpool) are also only tagged as > Informational. What is missing with regard to X25519? There is nothing missing as such - X25519 is a function that performs scalar multiplication on a curve known as curve25519. The X25519 function is in turn used to perform Diffie-Hellman key exchange. Neither X25519 nor curve25519 fit the OpenSSL Elliptic Curve API (largely due to design), hence it does not make sense for it to appear in 'openssl ecparam -list_curves', which would require it to be treated and manipulated as if it was a standard EC curve. > This is really weird. Although my test results for X25519 were similarly > confusing -- for simplicity, I'll provide some more results which were > restricted to explicitly testing secp384r1. [snip] > Error messages when failing against httpd: > > openssl s_client -connect <servername>:443 -servername <servername> > > -groups secp384r1 > CONNECTED(00000003) > 12254385780000:error:14FFF410:SSL routines:SSL_internal:sslv3 alert > handshake failure:/usr/src/lib/libssl/ssl_pkt.c:1205:SSL alert number 40 > 12254385780000:error:14FFF0E5:SSL routines:SSL_internal:ssl handshake > failure:/usr/src/lib/libssl/ssl_pkt.c:585: This is the server-side responding with a fatal SSL handshake failure alert - there are only a few cases where this will happen, the most likely of which is when there is no matching cipher suite. - Is there any other configuration that would limit the cipher suites in use? - What cipher suite is used if you connect without specifying -groups? - What type of public certificate are you using (RSA or ECDSA)? - If you're still unable to get to the bottom of it, try running 'openssl s_client' with -debug and provide the output.
