| |
Trust is not transitive: or why IRC over SSL is pointless. by slug
Monday 04. May 2009 at 20:00 BST
Several people have asked why we haven't added SSL support to snircd, there's two reasons:
- we haven't got around to it.
- we don't think it adds any real security to IRC.
The first should be believable! Here's our reasoning behind the second:
First some assumptions:
- The IRC network has only one server, and it's not compromised, and doesn't log anything.
- The server has an SSL certificate, with a fingerprint posted somewhere out of band to enable people to verify it is correct.
- Each server only supports IRC over SSL, i.e. there's no support for unencrypted connections.
- Each client has a uncompromised machine with logging turned off.
Say I create a new channel: #secret, and I invite two of my friends (Bob and Carol).
Now since I'm a paranoid computer scientist with a background in security, I verified that the certificate the ircd presented at connect was valid by checking its fingerprint, as did Bob.
Our connections to the ircd look like this:
ircd <---SSL---(securenet.org:real)---> Me
ircd <---SSL---(securenet.org:real)---> Bob
Since we verified the fingerprint of the ircd's certificate we are certain there's no man in the middle.
My second friend, Carol didn't bother verifying the certificate, she just clicked 'accept' in the dialog blindly (as most users do with SSL warnings, c.f. "Crying Wolf: An Empirical Study of SSL Warning Effectiveness", "Why Phishing Works").
Unbeknown to Carol, she's being attacked by Eve, Carol's connection looks like this:
ircd <---SSL---(securenet.org:real)---> Eve <---SSL---(securenet.org:fake)---> Carol
Eve presented her own certificate to Carol rather than that of the ircd, and can decrypt Carol's data, process it, then re-encrypt it and send it off to the ircd.
The ircd has no way of knowing that it is not talking to Carol, Carol is responsible for verifying the ircd's fingerprint, and she couldn't be bothered.
Clearly if Carol joins #secret, Eve can also see everything that's going on too, and the other users of the channel have no way of knowing their chat has been compromised.
Now why doesn't SSH and HTTPS suffer from the same problems?
Well they do, but the incentives are different.
If your connection to your SSH server gets MITM'ed, you are the only one to lose out as your server/shell gets rooted.
If your connection to your bank gets MITM'ed, you are the only one to lose out as the phisherman steal all your money.
If your connection to an IRC server gets MITM'ed, you likely not to even care, but other people in the channel probably do as they're talking about naughty things.
A lot of people will say that hey, that's not a problem, it's better than plaintext.
We don't agree, and feel that the false sense of security SSL provides is worse than no SSL at all.
If you'd like encryption the way we suggest to implement it is on top of IRC, several scripts say they provide this functionality.
As to how easy this sort of attack is, you can download software that'll do it for you for HTTPS sites, this uses various techniques such as ARP spoofing.
I'm sure there's something kicking around on efnet that'll do it for IRC with two clicks of a mouse.
Another obvious example of SSL IRC being broken is mibbit, which allows you to connect to an SSL'ed IRC server over HTTP. The ircd doesn't know it's really going over unencrypted HTTP, so it'll even let you into SSL only channels!
|
