View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005294 | unreal | ircd | public | 2019-05-21 19:48 | 2022-06-12 17:11 |
| Reporter | syzop | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 5.0.0-alpha1 | ||||
| Summary | 0005294: U5: update SSL/TLS ciphersuite | ||||
| Description | We currently create a RSA 4096 key but this is quite slow. Consider if we should create ecc by default instead. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
sign verify sign/s verify/s
160 bit ecdsa (secp160r1) 0.0001s 0.0002s 11738.5 4424.2
192 bit ecdsa (nistp192) 0.0001s 0.0003s 9896.5 3767.0
224 bit ecdsa (nistp224) 0.0001s 0.0002s 9503.8 6447.8
256 bit ecdsa (nistp256) 0.0001s 0.0001s 12765.3 11510.0 <==
384 bit ecdsa (nistp384) 0.0003s 0.0009s 3816.8 1144.8 <==
521 bit ecdsa (nistp521) 0.0004s 0.0006s 2309.9 1627.2
253 bit ecdsa (X25519) --invalid result--
256 bit is supposedly equivalent to 3072 bits RSA, well.. we don't want do downgrade, so that is off. 384 should be comparable with 7680 RSA It should noted that most research, including the last one I could find at https://scotthelme.co.uk/alexa-top-1-million-analysis-february-2019/ , shows that P-256 is A LOT more popular than P-384: Top Key Sizes: T: Bits: Sites: RSA 2048 bit 261,228 ECC 256 bit 47,807 RSA 4096 bit 24,823 ECC 384 bit 244 RSA 3072 bit 219 RSA 1024 bit 207 |
|
|
It's sad to see that certbot still does not have support for this. Only by doing it manually it can work. Sad. Tracking issue: https://github.com/certbot/certbot/issues/6492 Of course, there are alternative clients. I'm using acme.sh now. Installed ecc-384 on both irc.unrealircd.org machines, let's see how it goes. I can probably already update U5 though |
|
|
I just committed the work to use ECC and such, 384 at the moment. I'm however reading the Mozilla Server Side TLS 5.0 recommendations at the moment. They published it this weekend, but did not announce it yet. Combined with the speed figures and deployment figures from 2 posts above, I think it may be a better idea to go for P-256. That makes it harder to DoS. Actually, let's change the name of this ticket. |
|
|
** draft ** Mozilla Server Side TLS 5.0 recommendations have a nice table with information on client compatibility. Their Modern configuration is too new (requiring Android 10, OpenSSL 1.1.1, etc.). Their Intermediate ("recommended") one is of interest: "For services that don't need compatibility with legacy clients, such as Windows XP or old versions of OpenSSL. This is the recommended configuration for the vast majority of services, as it is highly secure and compatible with nearly every client released in the last five (or more) years." This has the following client compatibility, according to them (I also mention the browsers, just to paint the picture..): * Android 4.4.2 * OpenSSL 1.0.1 * Firefox 27 * Chrome 31 * Internet Explorer 11 (Win 7) * Java 8u31 Rationale: * All cipher suites are forward secret and authenticated * TLS 1.2 is the minimum supported protocol, as recommended by RFC 7525, PCI DSS, and others * ECDSA certificates are recommended over RSA certificates, as they allow the use of ECDHE with Windows 7 clients using Internet Explorer 11 * Windows XP (including all embedded versions) are no longer supported by Microsoft, eliminating the need for many older protocols and ciphers * While the goal is to support a broad range of clients, we reasonably disable a number of ciphers that have little support (such as ARIA, Camellia, 3DES, and SEED) * 90 days is the recommended maximum certificate lifespan, to encourage certificate issuance automation The rationale fits our ideas from https://www.unrealircd.org/docs/SSL_Ciphers_and_protocols perfectly. The Intermediate compatibility (recommended) specifies the following: * Protocols: TLS 1.2 and TLS 1.3 * Certificate type: ECDSA (P-256) is recommended, or RSA (2048) * DH: 2048 * TLS curves: X25519, prime256v1, secp384r1 * TLS1.2 ciphers: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256 * TLS1.3 ciphersuite: TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256 My comment: * Protocol: yes, agreed. * Certificate type: yes, agreed * DH: We dropped DHE a long time ago, we will only use ECDHE. <<< * TLS curves: agreed, but also offer secp521r1 * TLS1.2 ciphers: identical, with the exception of only offering ECDHE and not DHE * TLS1.3 ciphers: similar, different order, and we also offer TLS_AES_128_GCM_SHA256 in addition to TLS_AES_256_GCM_SHA384 I agree this would be nice and proper. Question is, when .. hm. |
|
|
Will look at this again at some later time. We don't want to piss off too many users either ;) |
|
|
Hm, so I changed this a while ago in UnrealIRCd (using secp384r1). Also UnrealIRCd 4 on irc.unrealircd.org (both servers) are running with the configuration that will be in U5. Haven't heard any complaints. Only saw more proof that this was a good idea, but I forgot the other source that was quoted to me (after it was done). |
|
|
I should also note that Debian 10 disabled versions older than TLSv1.2 by default. Debian 10 was released in July 2019. |
|
|
I'm OK with the current ciphersuite and protocols. Most notable is that we do require PFS in UnrealIRCd 5 (ECDHE) now. TLS 1.0 and TLS 1.1 are still allowed by default. Will disable TLSv1.0 and TLSv1.1 post-5.0.0. Browsers also have this scheduled around Q2 2020. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-05-21 19:48 | syzop | New Issue | |
| 2019-05-21 19:48 | syzop | Status | new => acknowledged |
| 2019-05-21 19:48 | syzop | Relationship added | child of 0005279 |
| 2019-05-21 20:55 | syzop | Note Added: 0020693 | |
| 2019-05-21 20:56 | syzop | Note Edited: 0020693 | |
| 2019-05-21 20:57 | syzop | Note Edited: 0020693 | |
| 2019-05-21 20:57 | syzop | Note Edited: 0020693 | |
| 2019-05-21 20:57 | syzop | Note Edited: 0020693 | |
| 2019-06-30 10:15 | syzop | Note Added: 0020753 | |
| 2019-06-30 11:34 | syzop | Note Added: 0020754 | |
| 2019-06-30 11:34 | syzop | Summary | U5: switch from rsa to ecc? => U5: update SSL/TLS ciphersuite |
| 2019-06-30 12:12 | syzop | Note Added: 0020755 | |
| 2019-06-30 12:12 | syzop | Note Added: 0020756 | |
| 2019-08-18 15:17 | syzop | View Status | private => public |
| 2019-08-18 15:59 | syzop | Note View State: 0020755: public | |
| 2019-08-18 16:07 | syzop | Note Added: 0020832 | |
| 2019-08-27 14:20 | syzop | Note Added: 0020859 | |
| 2019-08-27 14:20 | syzop | Note Edited: 0020859 | |
| 2019-10-06 07:47 | syzop | Assigned To | => syzop |
| 2019-10-06 07:47 | syzop | Status | acknowledged => resolved |
| 2019-10-06 07:47 | syzop | Resolution | open => fixed |
| 2019-10-06 07:47 | syzop | Fixed in Version | => 5.0.0-alpha1 |
| 2019-10-06 07:47 | syzop | Note Added: 0020937 | |
| 2022-06-12 17:11 | syzop | Note Edited: 0020832 |
