search

mumble-voip / mumble

Mumble is an open-source, low-latency, high quality voice chat software.
https://www.mumble.info
Other
6.14k stars 1.1k forks source link

Config option to set elliptic curve(s) for ECDSA/ECDHE #2578

Open Darkspirit opened 7 years ago

Darkspirit commented 7 years ago

Not found here https://github.com/mumble-voip/mumble/pull/1677

If there is a secp384r1 ECDSA certificate in use and you want long-term security https://www.keylength.com/en/3/ (Level 8), you want to set secp521r1 as curve for ECDHE (until curve448 has been landed in OpenSSL). But you can't just allow secp521r1, because the ECDSA cert then won't work with it's secp384r1 curve.

So there should be a config option like sslCurves=secp521r1:secp384r1 or sslCurves=secp521r1 or as default: sslCurves=auto

Please do it like: https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_ecdh_curve

mkrautz commented 7 years ago

This can be implemented with the elliptic curves API from Qt 5.5: http://doc.qt.io/qt-5/qsslconfiguration.html#setEllipticCurves

mkrautz commented 7 years ago

@TerraX-net's sketch for the config seems good to me.

Though there is ambiguitiy WRT consistent naming.

QSslEllipticCurve's short names are "conventional short name", with RFC 4492 and NIST's short names given as examples...

Do we want to introduce such ambiguity in our configuration? Or do only use OpenSSL names?

Darkspirit commented 7 years ago

Ah, you have to do the logic by yourself and can't let OpenSSL doing it? Maybe you can it just pass to OpenSSL? I haven't seen someone using such short names.

https://www.openssl.org/docs/man1.0.2/ssl/SSL_CONF_cmd.html The value argument is a colon separated list of curves. The curve can be either the NIST name (e.g. P-256) or an OpenSSL OID name (e.g prime256v1). Curve names are case sensitive.

The best solution would be if Qt would support to just pass everything to OpenSSL. But if that isn't possible: If someome would have "sslCurves=x448:x25519:secp521r1:secp384r1:prime256v1" in his config and OpenSSL doesn't support x448 (>=1.1.1) or x25519 (>= 1.1.0), use the next supported one. If no curve is supported, pass "auto" to OpenSSL, or try to ask OpenSSL which ones it supports or set your own default curve, e.g. secp384r1 (or if OpenSSL 1.1.0 is used: x25519). Notice: x25519 (>= OpenSSL 1.1.0) won't be listed under "openssl ecparam -list_curves" because it's not a classic curve.

Lartza commented 4 years ago

A (perhaps premature) concern was raised on IRC about the default curves to use when this gets implemented, so for documentation purposes from their request the curve order they suggested sane was X25519:secp521r1:secp384r1