On 02/04/17 17:15, Bob Beck wrote:
try connecting with openbsd nc rather than s-client
with ecdhe "auto" as well as ecdhe "secp384r1" in /etc/httpd.conf, I can
successfully negotiate a TLS cipher suite via nc -vvv -c <hostname> 443
However, nc doesn't give any output with regard to the negotiated curve
for ecdhe.
On Sat, Feb 4, 2017 at 09:13 Bob Beck <b...@obtuse.com> wrote:
On Sat, Feb 4, 2017 at 07:51 Andreas Bartelt <o...@bartula.de> wrote:
On 02/04/17 05:26, Joel Sing wrote:
On Wednesday 01 February 2017 15:41:29 Andreas Bartelt wrote:
Hello,
after reading the LibreSSL accouncement from today, I assumed that
specifying ecdhe "auto" in /etc/httpd.conf would enable X25519, P-256
and P-384 on current.
This is correct.
I've noticed that "auto" enables only curves x25519 and P-256 (which is
what I'd want to use - but somehow unexpected with regard to the
announcement).
Why do you believe this is the case?
Tested with a build of today's current:
- httpd started with ecdhe "auto" in /etc/httpd.conf
- then trying to connect via openssl s_client with -groups P-384 option
doesn't negotiate a cipher suite.
However, specifying -groups P-256 works. I don't know how to specify
x25519 with OpenBSD's openssl s_client (it's not yet listed in openssl
ecparam -list_curves output) but SSL Labs successfully negotiates via
x25519 and P-256 (but not P-384). P-384 doesn't seem to be enabled with
"auto".
Another confusing test result:
- httpd started with ecdhe "secp384r1" (P-384)
- then trying to connect via openssl s_client with -groups P-384 option
also doesn't negotiate a cipher suite!
However, SSL Labs successfully connects to httpd and confirms support
for secp384r1.
Can you reproduce this?
Diff is attached which clarifies the meaning of "auto" in httpd.conf.5.
There are some documentation improvements that could be used here,
however the
meaning of auto for httpd.conf.5 needs to refer to the meaning of "auto"
for
libtls (currently tls_config_set_ecdhecurve()). Otherwise libtls changes
and
httpd becomes out of date.
There currently seems to be no way to explicitly specify x25519, or to
specify multiple colon separated curves with the ecdhe statement. Would
it make sense to change semantics and make the ecdhe statement in
httpd.conf consistent with the recent changes to openssl s_client
-groups (e.g., to also allow more common names like P-256 instead of
prime256v1)?
Yes - tls_config_set_ecdhecurve() needs to change to accept the same
colon
separate list of priority ordered curve names, that
SSL_set1_curves_list()
accepts.
