View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005917 | unreal | ircd | public | 2021-06-19 02:31 | 2021-06-21 09:54 |
| Reporter | Polsaker | Assigned To | syzop | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 5.2.0 | ||||
| Summary | 0005917: "Throttled: Reconnecting too fast" message is sent in plaintext on TLS ports. | ||||
| Description | We have noticed that after many connection attempts we get the following error when using port 6697 (tls): *** Connection closed unexpectedly: Error: 140273682204544:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../deps/openssl/openssl/ssl/record/ssl3_record.c:332: After some debugging with ncat, we discovered that the error message is sent in plaintext, and that screws up the TLS handshake. This can even be replicated in irc.unrealircd.org: $ ncat irc.unrealircd.org 6697 ERROR :Closing Link: [redacted] (Throttled: Reconnecting too fast) - Email [email protected] for more information. | ||||
| Steps To Reproduce | 1. Attempt to connect many times to a TLS port with ncat 2. Admire the error message sent in plaintext | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Correct me if i'm wrong, but i think it's done on purpose. Large amount of connections triggering SSL handshakes would cause a significant load on the server. That's a usability/stability compromise. |
|
|
SSL/TLS is not really computationally expensive anymore... and it wasn't 10 years ago: https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html |
|
|
k4be is correct, this throttle check and also ZLINE and ban user { } are done very early, before DNS lookups, ident lookups, handshakes, etc. They send the error in plaintext for the same reason. This allows us to fight off drones/flood-attacks when they grow to rates of thousands per second. I have updated https://www.unrealircd.org/docs/Ban_IP_block to explain that a bit more. The article you linked to is a bit misleading, even 10 years ago. It uses weak 1024-bit RSA to show "how fast" things are (presumably to illustrate his/her point). 1024-bit RSA keys were already something that was not a good idea back then and CA's deprecated or advised against it in that same year 2010 already. https://www.globalsign.com/en/ssl-information-center/1024-bit-public-and-private-keys 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 is the new config for the default self-signed cert. At UnrealIRCd we try really hard to fight off drones/flooders with our protection systems. Like k4be says, the usability/stability compromise, this is considered an acceptable one. I'm not willing to sacrifice this flood protection. So case closed? Well, not really. There is an internal TODO item 0005532 to change this behavior depending on the load. That is: under low load allow the TLS handshake to proceed and send back a nice error message, under high load do as we do now. I have now changed that issue 0005532 from 'private' to 'public' and I'm closing this one. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2021-06-19 02:31 | Polsaker | New Issue | |
| 2021-06-19 08:16 | k4be | Note Added: 0022017 | |
| 2021-06-19 08:32 | Polsaker | Note Added: 0022018 | |
| 2021-06-21 08:58 | syzop | Assigned To | => syzop |
| 2021-06-21 08:58 | syzop | Status | new => closed |
| 2021-06-21 08:58 | syzop | Resolution | open => no change required |
| 2021-06-21 08:58 | syzop | Note Added: 0022020 | |
| 2021-06-21 09:53 | syzop | Note Edited: 0022020 | |
| 2021-06-21 09:54 | syzop | Note Edited: 0022020 |
