View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005532 | unreal | ircd | public | 2020-01-17 12:55 | 2023-05-18 13:28 |
| Reporter | syzop | Assigned To | syzop | ||
| Priority | normal | Severity | feature | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Product Version | 5.0.1 | ||||
| Fixed in Version | 6.1.1-rc1 | ||||
| Summary | 0005532: be more friendly to TLS users with error messages | ||||
| Description | Consider doing the SSL/TLS handshake even for throttling errors and such when the (reject) connection rate is below a certain amount per second. If it is higher than a certain rate, then fall back to the original behavior to reject the user instantly without handshake or looking at any data. Rationale: the current/original behavior is there so the ircd can handle floods, both in terms of traffic and in terms of CPU usage (the SSL/TLS handshake is quite costly after all). The downside of the current behavior is that TLS users don't see the error message, usually. This feature request tries to find a middle ground. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Now marked as 'public' and copy-paste from 0005917 with a bit more rationale: On typical hardware the number of TLS handshakes per second is not all that impressive. Remember, most ircds, including this one, use only one core. We previously shipped with a RSA 4096 default certificate which allowed only 212signs/sec on 4 year old hardware. That means you can bring the IRCd down completely if you did around 200 TLS connects per second. Or probably worse, since 1 handshake requires 1 sign operation but most likely uses more CPU than just that, some say handshakes/sec is 50% of signs/secs, so then it is only 100 handshakes/sec. That's a feasible attack from even a low-end cable connection. On the same machine, RSA 3072 could do 480signs/sec. Only with RSA 2048 you get over thousand (1440/sec). With ECC384 things are better at 3816 sign operations per second, which is one of the reasons why that became the config in 5.0.0 for the default self-signed cert. |
|
|
Currently working on this. This is the start: commit 89075e532a767509c06d1ae1e340c7e7023e5c65 (HEAD -> unreal60_dev, origin/unreal60_dev, origin/HEAD) Author: Bram Matthys <[email protected]> Date: Thu May 18 11:14:34 2023 +0200 Send throttling and some other error messages to SSL/TLS users (encrypted). This is the start of "be more friendly to TLS users with disconnect error messages" from https://bugs.unrealircd.org/view.php?id=5532 As that bug explains: Consider doing the SSL/TLS handshake even for throttling errors and such when the (reject) connection rate is below a certain amount per second. If it is higher than a certain rate, then fall back to the original behavior to reject the user instantly without handshake or looking at any data. Rationale: the current/original behavior is there so the ircd can handle floods, both in terms of traffic and in terms of CPU usage (the SSL/TLS handshake is quite costly after all). The downside of the current behavior is that TLS users don't see the error message, usually. This feature request tries to find a middle ground. Still a TODO item: * We don't detect high rates yet, so we only do this new behavior atm and not yet the old behavior during high connection rates. * Verify that error messages/behavior hasn't changed (too) much, like the throttling and the banning disconnect messages. |
|
|
This is now done in 6.1.1-git. It's spread over multiple commits. See this snapshot of the release notes for a good explanation: https://github.com/unrealircd/unrealircd/blob/9ea1e0e99c7125355e482d238409838ecacfb5c1/doc/RELEASE-NOTES.md#enhancements Commits: commit 9ea1e0e99c7125355e482d238409838ecacfb5c1 Author: Bram Matthys <[email protected]> Date: Thu May 18 13:23:22 2023 +0200 Update release notes a bit [skip ci] commit 815c97c81ef0cccab05c189a25e0d66e67f0c778 Author: Bram Matthys <[email protected]> Date: Thu May 18 13:21:44 2023 +0200 Update release notes on the new functionality of today. [skip ci] commit f804c5ed652d25143bad486dc42408b5431bd6c4 Author: Bram Matthys <[email protected]> Date: Thu May 18 13:15:17 2023 +0200 Add detection and set the high connect rate to 1000 per seconds. https://www.unrealircd.org/docs/FAQ#hi-conn-rate This finishes https://bugs.unrealircd.org/view.php?id=5532 commit 82dbc4a2971623d2d8eeafbe451ebe18a487f5f8 Author: Bram Matthys <[email protected]> Date: Thu May 18 11:57:24 2023 +0200 Add except ban { } for IRCCloud for maxperip & connect-flood. In both the release notes to illustrate and in example*.conf because this is generally a good idea. commit 9b9434e4426346b9234c1ae20944ffc8dd7e385d Author: Bram Matthys <[email protected]> Date: Thu May 18 11:48:44 2023 +0200 Delay throttling check until IP is resolved or failed to resolve. This so you can use throttling exceptions (eg in ELINE) on hostnames. That is, the above is during normal circumstances. Similar to previous commit we will turn this feature of during high connection rates. That is a TODO item. commit 89075e532a767509c06d1ae1e340c7e7023e5c65 Author: Bram Matthys <[email protected]> Date: Thu May 18 11:14:34 2023 +0200 Send throttling and some other error messages to SSL/TLS users (encrypted). This is the start of "be more friendly to TLS users with disconnect error messages" from https://bugs.unrealircd.org/view.php?id=5532 As that bug explains: Consider doing the SSL/TLS handshake even for throttling errors and such when the (reject) connection rate is below a certain amount per second. If it is higher than a certain rate, then fall back to the original behavior to reject the user instantly without handshake or looking at any data. Rationale: the current/original behavior is there so the ircd can handle floods, both in terms of traffic and in terms of CPU usage (the SSL/TLS handshake is quite costly after all). The downside of the current behavior is that TLS users don't see the error message, usually. This feature request tries to find a middle ground. Still a TODO item: * We don't detect high rates yet, so we only do this new behavior atm and not yet the old behavior during high connection rates. * Verify that error messages/behavior hasn't changed (too) much, like the throttling and the banning disconnect messages. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2020-01-17 12:55 | syzop | New Issue | |
| 2020-01-17 12:55 | syzop | Assigned To | => syzop |
| 2020-01-17 12:55 | syzop | Status | new => acknowledged |
| 2021-06-21 08:54 | syzop | View Status | private => public |
| 2021-06-21 09:00 | syzop | Note Added: 0022021 | |
| 2021-06-21 09:01 | syzop | Note Edited: 0022021 | |
| 2023-05-18 11:19 | syzop | Status | acknowledged => assigned |
| 2023-05-18 11:19 | syzop | Note Added: 0022860 | |
| 2023-05-18 13:28 | syzop | Status | assigned => resolved |
| 2023-05-18 13:28 | syzop | Resolution | open => fixed |
| 2023-05-18 13:28 | syzop | Fixed in Version | => 6.1.1-rc1 |
| 2023-05-18 13:28 | syzop | Note Added: 0022861 |
