On 02/05/17 07:41, Joel Sing wrote:
On Saturday 04 February 2017 15:51:02 Andreas Bartelt 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".
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].
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?
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?
No, it works correctly for me (OpenBSD -current, amd64).
With "tls ecdhe auto":
$ for group in X25519 P-256 P-384; do openssl s_client -connect localhost:443
-groups $group </dev/null 2>&1 | grep 'Server Temp Key:'; done
Server Temp Key: ECDH, X25519, 253 bits
Server Temp Key: ECDH, P-256, 256 bits
Server Temp Key: ECDH, P-384, 384 bits
With "tls ecdhe secp384r1":
$ for group in X25519 P-256 P-384; do openssl s_client -connect localhost:443
-groups $group </dev/null 2>&1 | grep 'Server Temp Key:'; done
Server Temp Key: ECDH, P-384, 384 bits
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.
TLS config of httpd has been stripped down for simplicity:
tls {
key "/etc/ssl/private/server.key"
certificate "/etc/ssl/server.crt"
ecdhe "secp384r1"
}
Server side:
one the same amd64 -current box with the same certs:
- httpd with ecdhe "secp384r1"
- nginx with ssl_ecdh_curve secp384r1;
external site:
- www.openbsd.org
Client side (on amd64 -current):
- openssl s_client -connect <servername>:443 -servername <servername>
-groups secp384r1
- eopenssl s_client -connect <servername>:443 -servername <servername>
-curves secp384r1
- nc -vvv -c <servername> 443
The following combinations were tested:
server httpd with ecdhe "secp384r1" & server nginx with ssl_ecdh_curve
secp384r1; (identical results)
connect via openssl [secp384r1]: fails
connect via eopenssl [secp384r1]: fails
connect via nc: succeeds
connect via SSL Labs: succeeds
connect via firefox: succeeds
LibreSSL 2.4.2 based client from OpenBSD current ~06/2016 on some older
test laptop:
connect via openssl [-groups was not yet available]: succeeds
then installed OpenSSL 1.0.2h from ports:
connect via eopenssl [without -curves option]: succeeds!
connect via eopenssl [with -curves secp384r1]: fails!
connect to www.openbsd.org:443
connect via openssl [secp384r1]: succeeds
connect via eopenssl [secp384r1]: succeeds
connect via nc: succeeds
I can't make any sense out of this.
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:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Start Time: 1486287427
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
> eopenssl s_client -connect <servername>:443 -servername <servername>
-curves secp384r1:
CONNECTED(00000003)
22708595331744:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake failure:s23_clnt.c:769:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 308 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1486287464
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
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.
