On 02/06/17 14:44, Joel Sing wrote:
On Sunday 05 February 2017 17:05:40 Andreas Bartelt wrote:
- What type of public certificate are you using (RSA or ECDSA)?
ECDSA with P-256. Certificate signed by letsencrypt (via RSA).
Must-staple is enabled - that's why I'm also using the ocsp line for
testing.
Ah, this was the missing piece of information.
In order to use ECDSA the client must support the curve used for the server
certificate, otherwise when the server signs the server key exchange, the
client will not be able to verify the signature. In the case where you
announce that the client only supports P-384, any ECDSA ciphers are considered
to be invalid for this session, effectively resulting in no shared ciphers and
the handshake failure alert.
Yes, right - thanks. I wasn't aware that this is actually a MUST
requirement from RFC 4492. I'm quite surprised that the "Supported
Elliptic Curves Extension" is also used in order to specify any allowed
curves for use in the context of certificates. I think this is quite
inconsistent but it's what this RFC seems to mandate. It's inconsistent
because there is no such binding with regard to -ECDHE-RSA- or -DHE-RSA-
cipher suites.
I've successfully tested a P-384-based certificate which allowed me to
explicitly specify -groups secp384r1 for ECDHE on the client side.
In order for this configuration to work you need to include P-256 in the client
supported groups. Specifying groups as "P-384:P-256" should still get you
P-384, depending on the server configuration and whether the preference for a
curve is based on the client or server preference (for libtls and hence httpd,
it will be server preference).
Test 1 (with P-384-based certificate): httpd/libtls's preference seems
to be hard-coded with the following order: X25519, P-256, P-384. In this
specific case, the httpd's default tls configuration negotiates
ECDHE-ECDSA-AES256-GCM-SHA384 which has a target security level of 256
bits. I suppose P-384 would be the preferred choice for ECDHE in this
case since the certificate also uses P-384 the other two group choices
effectively lower the overall security level to ~128 bits? [also see RFC
7919 for a similar discussion wrt RSA key size and FFDHE parameter choice]
Test 2 (with P-256-based certificate): since httpd's preference is
hard-coded and P-256 must be specified due to the certificate's public
key, P-384 is actually never selected for ECDHE - this was what I
initially noticed with regard to the ecdhe "auto" option. For example,
secp384r1:prime256v1:X25519 effectively selects X25519 for ECDHE.
I think it would be beneficial to allow to explicitly specify multiple
groups with the ecdhe statement in httpd.conf, and also to respect their
order.
