hn-classics/_stories/2009/11492038.md

113 lines
3.8 KiB
Markdown

---
created_at: '2016-04-13T20:43:33.000Z'
title: Why IRC over SSL is pointless (2009)
url: https://www.quakenet.org/articles/99-trust-is-not-transitive-or-why-irc-over-ssl-is-pointless
author: jordigh
points: 57
story_text:
comment_text:
num_comments: 70
story_id:
story_title:
story_url:
parent_id:
created_at_i: 1460580213
_tags:
- story
- author_jordigh
- story_11492038
objectID: '11492038'
year: 2009
---
Written by **slug** on **Monday 04 May 2009**
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\!