3

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.1 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.

  • The information you have provided (while plentiful) is still not-quite-sufficient. Is there a known shared secret password between the IRC server & these privileged operators? – Samuel Allan Feb 8 '18 at 3:38
  • @SamuelAllan I'm interested in current existing implementations, though preferably not obscure ones. Hence the reason I struck the hash-related content out of the question. – autistic Feb 8 '18 at 4:55
3
+200

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.

  • This does not answer OP's threat model. – forest Feb 2 '18 at 13:15
  • I simplified it, because you do not need more complicated threat models, when the most basic things are at risk. So you can answer the question already at that point with "it is not pointless". And yeah I know quite a few networks tell you they do support TLS because they think they do not need it. – allo Feb 2 '18 at 13:18
  • But we're not here to answer a question with our own threat model. It may be that OP only cares about integrity, not confidentiality (for example, he uses OTR for all private messages, and only talks in already publicly-logged channels). – forest Feb 2 '18 at 13:21
  • I see your point. I added a paragraph what I think about active attacks. I guess the local network admin is the most plausible scenario. – allo Feb 2 '18 at 13:38
  • 1
    Feel free to wait with accepting, I think some more discussion is interesting for such topics. I started with the general "Always use TLS" advice as well before @forest told me to expand more on the detailed threat model. – allo Feb 3 '18 at 18:53
1

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)

  • Well, I would not personally roll an auth system that reuses salts (at least, not weakly), just as I wouldn't roll a crypto that repeats nonce but... self-crit trigger... you have a valid point! It doesn't exactly answer the questions at hand, but it does give some advice to the IRC dev community, which often seems to turn a blind eye to idioms accepted throughout programming in all other realms: Don't needlessly reinvent the wheel, (especially) don't (ever) authenticate plaintext and use the most appropriate tool for the job... – autistic Feb 3 '18 at 10:32
  • Can you work on addressing the questions at hand, as opposed to the solutions? Because right now the problem is that the development community I'm talking about seem blind to the issues (and thus unwilling to fix them), and need to be made aware... or I need to be told that I'm wrong... – autistic Feb 3 '18 at 10:36
  • @Sebivor My solution is to use TLS! Anything else is Overly complex, Flakly, and Insecure. – DarcyThomas Feb 3 '18 at 10:40
  • I think you should take some time to read the question carefully, and identify what it is I'm asking... Extract the questions, literally, copy and paste the statements which end in a question mark into notepad, and ask yourself... "Am I answering this?". – autistic Feb 3 '18 at 10:42
  • Don't just answer the title. There are three paragraphs. Each paragraph has a question. If you quote them, answer yes/no, give citations/examples/supporting reason where possible, then you have most likely answered my questions, and you get my tick. – autistic Feb 3 '18 at 10:45
0

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.

  • You seem to have missed some key details. For a start, I already mentioned that we have salted forms of authentication that are unfeasible to break. There's no need for a signed OPER, and even if there were, you seem to have neglected the entire middle paragraph of my question where I raise that the routers between the server and the oper in question may tamper with, misroute or otherwise hijack connections. Would you mind addressing THAT part of the question? – autistic Feb 2 '18 at 6:38
  • Additionally, when we talk about attacks, you need to keep in mind that attackers are opportunistic. For example, there are DNS hijack attacks that have only a slim window, perhaps making it "unlikely" as you would describe that someone would perform a successful hijacking, yet a patient attacker will be well prepared for the opportunity, right? Would you mind addressing that in your answer, too? Because as it currently stands, I think you're in denial/brushing some things aside. – autistic Feb 2 '18 at 6:40
  • Do you think there might be situations where an attacker might be able to... reasonably guess... how many bytes they think their target has received? ... and what if they send a number that's too high? Would that still cause a reset? My understanding is that such a "gap" would be evident to the attacker in the lack of timely ACK response, allowing the attacker to... try to "guess" to fill in the gap... after some time. Is my understanding of retransmission rules correct? – autistic Feb 2 '18 at 7:00
  • I do recall being taught that TCP allows packets to be delivered out of order, and reordered by the kernel as a result. How might this affect the likelyhood (I think you meant "feasibility" or "difficulty", by the way) of exploitation? – autistic Feb 2 '18 at 7:04
  • 3
    @Sebivor: it sounds like the answer totally misses the point for you... in which case you can down vote it and obviously not accept it as your chosen answer. You may have gone on a bit more of a rant than appropriate here. – Jeff Ferland Feb 2 '18 at 18:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.