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.
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:
Android 4.4.2+, released October 2013
Chrome 31+, released August 2016
Firefox 27+, released February 2014
IE 11 (Win 7 and Win 10), released October 2013
Edge (all versions)
Java 8u31+, released January 2015
OpenSSL 1.0.1+, released March 2012
Safari 9+, released September 2015
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!
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:
- Android 4.4.2+, released October 2013
- Chrome 31+, released August 2016
- Firefox 27+, released February 2014
- IE 11 (Win 7 and Win 10), released October 2013
- Edge (all versions)
- Java 8u31+, released January 2015
- OpenSSL 1.0.1+, released March 2012
- Safari 9+, released September 2015
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.
@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.
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):
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.
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.
@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.
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 (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.
@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)
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.
@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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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.