Allow ECDH curve selection (WIP)

[Varbin]

This PR is a fix for #713 (How can I use a "stronger" ECDH curve?).

Current state:

• It works, but details could be improved.

Changes:

• The config option ecdh-curves allows to set curves for the ECDH key exchange.
• Possible options are:
  • auto: Calls SSL_CTX_set_ecdh_auto if required and possible. It falls back to prime256v1.
  • a list of curve names (e.g. brainpoolP512r1:brainpoolP384r1:brainpoolP256r1:prime256v1) which are passed to SSL_CTX_set1_curves_list if possible. This requires a fairly recent OpenSSL/LibreSSL version. In recent OpenSSL versions TLS 1.3 group names may work, too.
  • a single curve name (e.g. prime256v1) which is passed to SSL_CTX_set1_curves_list or the combination OBJ_sn2nid->EC_KEY_new_by_curve_name->SSL_CTX_set_tmp_ecdh. While it sets only a single curve, it will work with any OpenSSL supporting ECDH.
    Update: Not anymore. Usage of OpenSSL 1.0.1 is discouraged. OpenSSL 1.0.1 is not supported by the OpenSSL-team anymore.
• h2o will crash on errors while setting up ECC-curves for ECDH.
• Update: The option SSL_OP_SINGLE_ECDH_USE will be set if possible.

To-Do:

• add tests (how?)
• update documentation (how?)
• solve questions below

Questions (@kazuho):

• Should the option SSL_CTX_set_options(ssl_ctx, SSL_OP_SINGLE_ECDH_USE) be set? A similar one is set for normal Diffie-Hellman.
  Solved: Will be set.
• Should a better default than auto be set? On LibreSSL auto is a good default. Good curves might not get detected by a simple detection script which may leave the default a better one. On the hand auto can be bad: Currently on (older) OpenSSL it allows old 160-bit curves by default.
  Solved: No (current behavior).
• Shall a warning be issued if SSL_CTX_set_ecdh_auto is not available and auto falls back to prime256v1?
  Solved: No (current behavior).

[kazuho]

This is something that we definitely need. Thank you very much for working on the PR.

Should the option SSL_CTX_set_options(ssl_ctx, SSL_OP_SINGLE_ECDH_USE) be set?

Yes. Please call the function whenever SSL_OP_SINGLE_ECDH_USE is defined.

Should a better default than auto be set? On LibreSSL auto is a good default. Good curves might not get detected by a simple detection script which may leave the default a better one. On the hand auto can be bad: Currently on (older) OpenSSL it allows old 160-bit curves by default.
Shall a warning be issued if SSL_CTX_set_ecdh_auto is not available and auto falls back to prime256v1?

IMO the principle should be that unless there is a bug, we should preserve the current behavior as-is, at the same time providing the users to change the curve being used. Considering that, how about an approach like below:

• always call SSL_CTX_set_ecdh_auto if it is available, or set prime256v1 if not
• then, if curves are specified by the user, call SSL_CTX_set1_curves_list if it is available, or generate an error if it is unavailable

Note that you need to call SSL_CTX_set_ecdh_auto even if you are calling SSL_CTX_set1_curves_list, see https://bugs.ruby-lang.org/issues/12324.

[Varbin]

then, if curves are specified by the user, call SSL_CTX_set1_curves_list if it is available, or generate an error if it is unavailable

Shouldn't it be possible to set a single curve if SSL_CTX_set1_curves_list isn't provided? It might be required by certain standards to use h2o (e.g. PCI DSS which disallows 160 bit curves) and unfortunately some server software can be really old (e.g. Debian Jessie with OpenSSL 1.0.1).

On the other hand it might create some confusion why a complete list cannot be passed.

[kazuho]

@Varbin

Shouldn't it be possible to set a single curve if SSL_CTX_set1_curves_list isn't provided? It might be required by certain standards to use h2o (e.g. PCI DSS which disallows 160 bit curves) and unfortunately some server software can be really old (e.g. Debian Jessie with OpenSSL 1.0.1).

My understanding is that both SSL_CTX_set_ecdh_auto and SSL_CTX_set1_curves_list appeared in OpenSSL 1.0.2, and the call to the former is required if we want to use ECDH in any form (that's what I have read from https://bugs.ruby-lang.org/issues/12324, maybe I am wrong).

Assuming that is correct, I'd anticipate that our users willing to prohibit 160-bit curves (which are enabled by SSL_CTX_set_ecdh_auto) can do so by explicitly specifying the curves they want.

(And FWIW, I am fine with disabling 160-bit curve by default, possibly by having our own list of default curves).

I do not think that we would want to support OpenSSL 1.0.1 and earlier, considering the fact that they do not support ALPN (which is a prerequisite for HTTP/2). Note that Chromium has dropped support for NPN (the predecessor of ALPN) in 2016 (see https://blog.chromium.org/2016/02/transitioning-from-spdy-to-http2.html).

[Varbin]

The problem with a self created default list is, that compared to a cipher list, curves cannot be excluded. So it will be difficult to keep it up to date so auto seems to be the right choice here (curve detection is possible with OBJ_sn2nid but takes a lot of work and might make it too complicated. This might be topic for a future PR.

SSL_CTX_set_ecdh_auto will already always be called whenever possible (OpenSSL 1.1.0+ does not require it anymore, as it will be set by default).

The current code in this PR supports OpenSSL 1.0.1 and earlier.

[Varbin]

@kazuho As you suggested, custom curves cannot be set with OpenSSL <= 1.0.1 anymore.

About tests: Is there some trivial way to test curves from picotest + Test:More? I could write one with Bash + testssl.sh and as it supports JSON output is supported. But I guess this won't integrate well into the testing framework.

[Varbin]

Idea for tests: Try connections with different parameters against different server configurations.

server curves	client curves	connection
default (auto)	default	✓
P-384:P-521	P-256	✗
P-384:P-521	P-384	✓
P-384:P-521	P-521	✓