This sets up ECDH key exchange, when compiling against OpenSSL
that supports EC. Then ECDHE-RSA and ECDHE-ECDSA ciphersuites
can be used for SSL connections. Latter one means that EC keys
are now usable.
The reason for EC key exchange is that it's faster than DHE
and it allows to go to higher security levels where RSA will
be horribly slow.
Quick test with single-threaded client connecting repeatedly
to server on same machine, then closes connection. Measured
is connections-per-second.
Key DHE ECDHE
RSA-1024 177.5 278.1 (x 1.56)
RSA-2048 140.5 191.1 (x 1.36)
RSA-4096 59.5 67.3 (x 1.13)
ECDSA-256 280.7 (~ RSA-3072)
ECDSA-384 128.9 (~ RSA-7680)
There is also new GUC option - ssl_ecdh_curve - that specifies
curve name used for ECDH. It defaults to "prime256v1", which
is the most common curve in use in HTTPS. According to NIST
should be securitywise similar to ~3072 bit RSA/DH.
(http://www.keylength.com / NIST Recommendations).
Other commonly-implemented curves are secp384r1 and secp521r1
(OpenSSL names). The rest are not recommended as EC curves
needed to be exchanged by name and need to be explicitly
supprted by both client and server. TLS does have free-form
curve exchange, but few client libraries implement that,
at least OpenSSL does not.
Full list can be seen with "openssl ecparam -list_curves".
It does not tune ECDH curve with key size automatically,
like DHE does. The reason is the curve naming situation.
---
doc/src/sgml/config.sgml | 13 +++++++++++++
src/backend/libpq/be-secure.c | 32 ++++++++++++++++++++++++++++++++
src/backend/utils/misc/guc.c | 16 ++++++++++++++++
3 files changed, 61 insertions(+)
