mirror of
https://github.com/dehydrated-io/dehydrated.git
synced 2026-01-13 23:23:32 +01:00
Consider making ECDSA (P-256) the default certificate type #416
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @april on GitHub (Jun 21, 2019).
I'm not sure if this is the ideal place to post this, but I just wanted to give people a heads-up that Mozilla's future "Server Side TLS" guidelines will recommend ECDSA certificates for the Intermediate configuration level. This is one of the most commonly used TLS configurations for servers across the internet.
https://github.com/mozilla/server-side-tls/issues/178
https://github.com/mozilla/server-side-tls/issues/254
https://ssl-config.mozilla.org/
In our research, we found that ECDSA and RSA certificates were equally compatible with the vast majority of clients across the internet, comprising this set of clients:
The reason why we are recommending ECDSA certificates over RSA certificates is that they give IE11 clients on Windows 7 access to ECDHE for key exchange; with RSA they are limited to classic DHE. My apologies if this project already uses ECDSA by default; I believe the default config shows RSA, but I'm not sure what happens if it remains uncommented.
Please let me know if you have any questions! Thanks!
@robert-scheck commented on GitHub (Jun 26, 2019):
Which impact would this change have to non-browsers, e.g. e-mail clients (MUAs), mails servers (MTAs), XMPP servers/clients, FTP servers/clients? There are more consumers of certificates rather just browsers.
@april commented on GitHub (Jun 26, 2019):
Almost all of them are built upon OpenSSL, which has supported ECDSA since version 1.0.0, which was released 2010. It was introduced with TLS 1.2, so I would be fairly surprised if any systems didn’t support it, barring cipher suite misconfigurations.
@april commented on GitHub (Jun 26, 2019):
One thing that some systems do is use ECDSA for new certificates and use the existing signature scheme for certificate renewals. Caddy is one such example.
@lukas2511 commented on GitHub (Oct 4, 2019):
I agree that by now it's really time to do this change. I'll have to implement a solution for keeping rsa on renewals so that existing setups don't break on update, and I'll have to do at least some compatibility testing, but I guess it'll be fine.
@lukas2511 commented on GitHub (Dec 10, 2020):
secp384r1 is now the default :)
@april commented on GitHub (Dec 10, 2020):
::long stream of party emoji here::
Nice work!
@felix-engelmann commented on GitHub (Feb 7, 2024):
Be aware that if you use a secp384 key for a mailserver, there are incompatible MTAs which don't support the curve yet.
They will send a Client Hello with
Extension: supported_groups (len=4)
Type: supported_groups (10)
Length: 4
Supported Groups List Length: 2
Supported Groups (1 group)
Supported Group: secp256r1 (0x0017)
Instead of e.g. postfix which sends:
Extension: supported_groups (len=12)
Type: supported_groups (10)
Length: 12
Supported Groups List Length: 10
Supported Groups (5 groups)
Supported Group: x25519 (0x001d)
Supported Group: secp256r1 (0x0017)
Supported Group: x448 (0x001e)
Supported Group: secp521r1 (0x0019)
Supported Group: secp384r1 (0x0018)
According to https://search.censys.io/search/report?resource=hosts&q=services.port%3D25&virtual_hosts=EXCLUDE&field=services.tls.certificates.leaf_data.pubkey_bit_size&num_buckets=50
Total 60,510,551 100.0%
2048 30,047,512 49.66%
4096 3,104,376 5.13%
1024 933,672 1.54%
256 783,551 1.29%
384 375,648 0.62%
3072 253,916 0.42%
512 10,259 0.02%
Only half a percent of mail servers use a P384 cert on port 25.
Porbably a P256 is a more widely accepted default for MTAs.