Is SSL/TLS pointless for IRC?

Question

Assuming a network which has absolutely no support for SSL/TLS, as rationalised by this blog post, is it possible guarantee the security of privileged operator connections?

There are already mechanisms which allow us to oper using salted password hashes, which should be unfeasible to attack.¹ As I understand, traffic is routed between devices I have no control over, and those devices could trivially hijack an already established connection. Should I be concerned that any router between my IRC client at home and my server hosted in a different country could steal my authenticated, yet insecure connection, and use it to wreak havoc?

Furthermore, I'm aware that IP addresses are often allocated dynamically to home internet connections such as mine, and so my IP address might change on occasions. When such a DHCP renewal event occurs, is it possible that some other user of my ISP might be able to steal an authenticated, yet plain-text (insecure) connection?

---

^{Footnote: I've chosen to leave that there to keep previous answers relevant, but I've realised it's not really worth mentioning. If you'd like to include attacks against salted oper authentication, that would probably be a valuable discussion, but otherwise anything seemingly relevant to current IRCds that don't support SSL/TLS (such as ircu) should be fine.}

Answer 1

No it is not pointless. The easiest example: You want nobody to know what's your nickname, in which channels you are and what you're writing in queries (private messages).

To address the concrete question

Should I be concerned that any router between my IRC client at home and my server hosted in a different country could steal my authenticated, yet insecure connection, and use it to wreak havoc?

In theory you should be concerned, as every router can do so. In practice it depends on who might want to do so and what he can do. I would think the people who both may want it and can do it are inside your LAN.

Your network admin might take over your connection and this won't be too complicated. You do not need to think about messing with TCP-Packets of your stream. He may just have a TCP-Proxy running, which can be as simple as two netcat instances and a firewall rule.

Answer 2

The short answer is NO, it is not pointless. You should use TLS.

What would stop a bad person from seeing your salted hash go by, and reusing it? Either just reusing or as a MitM attack.

'Mechanisms to oper using salted password hashes', just cries out as 'roll your own crypto'. (I could be wrong but,) Remember the first rule of Crypto is: You are doing it wrong.

Protecting against replay or MitM attacks, without using standard secure channel mechanisms is more than likely to be:

1. Overly complex
2. Flaky
3. Insecure

<Sarcasm>

Maybe you could do it with some public-private crypto (or shared secret (which you shared over a secure channel right?!?...)), signing each message, oh and don't forget to add a non repeating nonce.

</Sarcasm>

Oh but that would be 1. Overly complex 2. Flaky and still 3. Insecure!

TLS is standard, well understood, battle tested, and easy to implement. That is pretty much the only way to reliably secure against replay and or MitM attacks here.

Now maybe you don't trust TLS CAs (because state actors), well my response to that is: Don't IRC about things, that will annoy state actors, over plaintext!!!

---

Edit: to address the comments:

1. If setup correctly (Certs signed by a trusted CA) TLS should work fine. Just because some users will not use it correctly does not mean you should make it insecure for all users, especially privileged ones. (The blog post seems to describe an incorrectly configured system, so its point is moot)

2. There are feasible attacks to (correctly) salted passwords* used in this way (Replay and MitM). So any router (or someone listening as you use an open wifi connection) along the way could mess with you.

3. IP address changes (or NATed IP addresses) will only affect you if your server is using IP address white listing. Which is insufficent to protect you in the scenario you have described.

So in conclusion: use correctly configured TLS, to secure your all your communications , including authentication information. Otherwise you could get burnt by a bad person. Also educate your users to not just blindly click OK all the time.

Look at letsencrypt.org as a way to get legit CA signed certs for free. (note you will need to setup a renewal mechanism as they need to be refreshed every 90 days)

*(Salting only really protects you when you loose data at rest, not data in flight like this)

Answer 3

Using the standard IRC protocol, no, you can't guarantee security over a plaintext channel. With a modified OPER command set using some kind of signed commands, you would be able to prevent others from forging commands.

As to taking over your connection due to an IP change, this would be incredibly unlikely. Your IP would need to be passed on to an attacker almost immediately (so the connection doesn't time out). The attacker would need to be in a position to respond to the first packet that comes in, and it would need to be an ACK packet (to get the right sequence numbers). Anything else would cause a connection reset.