View Issue Details

IDProjectCategoryView StatusLast Update
0005532unrealircdpublic2021-06-21 09:01
Reportersyzop Assigned Tosyzop  
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status acknowledgedResolutionopen 
Product Version5.0.1 
Summary0005532: be more friendly to TLS users with error messages
DescriptionConsider 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.
TagsNo tags attached.
3rd party modules



2021-06-21 09:00

administrator   ~0022021

Last edited: 2021-06-21 09:01

View 2 revisions

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.

Issue History

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 View Revisions