
Why IRC over SSL is pointless (2009) - jordigh
https://www.quakenet.org/articles/99-trust-is-not-transitive-or-why-irc-over-ssl-is-pointless
======
Sidnicious
I use IRC over SSL to avoid leaking my credentials (e.g. NickServ password).
You can certainly assume that at least one person in a given channel is
logging or on a compromised connection, but that's not the whole point.

~~~
15155
I wonder if some networks provide auth over TLS on the web:

\- User visits IRC network website

\- User logs in

\- User is given a single-use token or command containing a token

\- User sends token to NickServ

\- User is authenticated

Not invincible to MITM, but at least it avoids leaking credentials in
plaintext.

~~~
raimue
Many users run a permanent IRC connection with a bouncer or just run
irssi/weechat in screen/tmux on a server. There may be occasional reconnects
for them due to netsplits etc. Usually they also configure their
bouncer/client to automatically authenticate when they connect.

Using any sort of authentication involving a separate channel would stop them
from authenticating without user interaction. Unless of course it could also
be automated. However, I doubt it is easy enough to create a standard for
this.

If your only goal is to stop leaking the password in cleartext, that could
also be achieved using established standards such as SASL or a challenge-
response mechanism such as CRAM-MD5.

~~~
ibotty
Not that CRAM-MD5 is particularly secure.

------
Tehnix
Sorry, but this argument is just so damn stupid. It's on the level of, "we
don't have passwords for accounts, because people could bruteforce them
anyways"...

They are basically arguing that while SSL might cover 9/10 cases, because it
doesn't cover that 1 case, they will leave the other 9 open.

~~~
na85
IRCops have a long history of being change-averse and vitriolic. This just
looks like more of the same.

~~~
Tehnix
I'm just so baffled, since it is almost literally just creating a certificate
and you are done (I run a couple of IRC servers myself). Even a self-signed
certificate is better than none at all.

~~~
na85
You're talking about people who make heavily-entrenched ideologies about minor
technical distinctions into an Olympic-level contest of stubbornness and
scorn.

------
wibbler2
author here, note that my view has somewhat changed from that which I held in
2009 from "it's silly" to "we'll do it if when we solve a few problems first."

PKI deployment in a semi-untrusted environment is still very difficult.

freenode messed it up by sharing their private key between all irc servers,
which are hosted on other people's hardware. they had servers compromised in
this period, and no forward secrecy enabled, so any TLS traffic captured over
those multiple years has been effectively compromised.

presumably this was done to save money on CA fees, a problem that's gone away
now that letsencrypt exists.

note that when I wrote the article the general assumption was that openssl was
a reasonably good piece of software... not many people hold this view today.

an ircd isn't as easy to upgrade as nginx, upgrading them each time there's a
new openssl vulnerability would make for a very splitty network.

separating the tls termination from the ircd (and locking it in a seccomp
sandbox) would allow it be restarted independently... and is in progress.

(re: nickserv passwords, our channel service supports CRAM-MD5, so that isn't
really a problem)

~~~
asuffield
I used to do most of the dev work on freenode for a while, years ago. I said
no to the ssl plans, for pretty much the reasons you describe. After I moved
on, some people built the bad thing anyway, and we saw how well that worked
out.

The lesson that I take from this is that saying "no" to people who want to
build a bad idea isn't sufficient, because it's just pitting your energy
against theirs. You need to lick the chocolate by building something that is
good enough to remove the incentive to build the bad idea, without replicating
its worst flaws.

I should have built the damn thing myself.

~~~
pfg
Out of curiosity, do you know if they've changed how they distribute their
keys?

This seems like a perfect candidate for something like CloudFlare's Keyless
SSL, but I'm not aware of any ircds having support for something like that.

------
sanqui
If I don't connect to the IRC server with SSL/TLS, somebody could sniff my
NickServ password and impersonate me. I think this is case enough for TLS
support.

~~~
jemfinch
They can still do that under SSL/TLS with a MITM attack.

~~~
pfg
How is that? Unless you're accepting self-signed certificates, that seems hard
to pull off unless you're a state actor.

------
RealityVoid
So his reasoning is that they didn't implement SSL because SSL can be broken
my accepting invalid certificates.

It seems true that the payoff is higher for a successful MITM for IRC than a
normal website, but such a MITM is far from guaranteed to happen.

Saying that such or such method of protection can be broken so it shouldn't be
implemented means we shouldn't implement _any_ security measure - since there
is not one 100% secure measure.

~~~
dmix
I believe the distinction here is there would still be security against a
passive attacker, just not an active one (via MITM or man-on-the-side). Which
is what makes it worthwhile IMO as MITM is noisier than passive collection.

------
LamaOfRuin
Numerous times over the past 15 years, IRC over SSL has been the easiest way I
was able to connect to IRC networks at all when a network operator had a
blanket ban on IRC traffic and/or the common IRC ports. These were mostly
public wifi networks, and networks run by large institutions that were
probably just trying to protect themselves and their users from botnet
traffic, the same way they wouldn't let your compromised computer run a spam
server. They were not malicious, but were weighing the costs to niche users
against the benefits to their network.

VPNs and proxies could also obviously work, but introduce their own
difficulties.

------
yzmtf2008
No security is ever perfect, but that doesn't mean we should stop implementing
all imperfect security measures.

------
n3t
Private messages (next to credentials leak) are another reason for using
SSL/TLS.

~~~
jordigh
No, because you have no guarantee that you're talking to whom you think you
are. Private messages still go through the central server, and Eve could be
listening on Carol's connection.

~~~
pfg
Many ircds I'm familiar with include a "<user> is using a secure connection"
message in their WHOIS response, so this is easily verifiable. Obviously, it's
still not E2E-encrypted, so if you don't trust the ircd, you should use an
additional layer that provides E2E encryption.

~~~
wibbler2
one of the main points of the article is that people don't check fingerprints,
and that you should use encryption layered on top of IRC if you want any real
privacy

~~~
pfg
Is there any evidence that IRC users are somehow more likely to accept self-
signed SSL certificates? The IRC clients I'm familiar with rely on the OS
trust store, just like most web browsers do.

To me this seems like saying a webmail site shouldn't use SSL because the
recipient might also use a webmailer and happily accept a self-signed
certificate and bypass the browser warning. Sure, it's no replacement for E2E
crypto, but to me that's a clear case of perfect being the enemy of good.

~~~
blibble
as an example, irssi from debian jessie doesn't verify the certificate at all,
or even display that it's accepted an untrusted certificate

(I just tried it)

------
r1ch
You'd think an IRC network targeted towards gamers would make extra sure to
keep things secure and private. Supporting SSL/TLS and enabling IP cloaking by
default would go a long way to improving privacy on Quakenet.

~~~
justinsaccount
> You'd think an IRC network targeted towards gamers would make extra sure to
> keep things secure and private.

I don't think that. Why would you think that?

Why would gamers care more about privacy and security than groups like
programmers or sysadmins?

~~~
tetromino_
Because gamers sometimes attract the attention of sociopathic teenagers [1] in
a way that programmers typically don't.

[1] [http://arstechnica.com/tech-policy/2015/05/teen-pleads-
guilt...](http://arstechnica.com/tech-policy/2015/05/teen-pleads-guilty-
to-23-charges-of-swatting-harassing-online-game-rivals/)

------
zxv
The author argues that because clients may blindly accept SSL certificates for
an IRC server, that certificates are pointless.

One possible fix is, have the IRC client refuse to connect to a server if the
certificate is invalid.

------
kenshaw
It's interesting that this is from 2009 -- even in 2009 it was trivial to sit
at public wifi points or plugged into corporate networks and grab credentials
as they went over the air/wire unencrypted -- even more so then since at the
time the public hadn't yet caught on and SSL was more rare on sites/services
than it is today, and since not everyone yet had a smartphone in their pocket
with highspeed net access.

In my opinion, implementing SSL is really more about preventing mass capturing
(and later forging) user identities/credentials than it is about trying to
create either perfect security or preventing an attack on a server.

------
koenigdavidmj
The mere existence of a connection is likely to be the most interesting bit of
information to law enforcement. There's been at least one case (that of Jeremy
Hammond) where they determined someone's identity by correlating their
connections and disconnections to their comings and goings from their house.

~~~
tekromancr
IIRC, The Hammond/Stratfor case was that they had narrowed him down to a
likely region. Hammond had also mentioned in chat that he had been busted for
pot possession. All they had to do was look through the usual suspects, who
lived within the midwestern United States, and who had recently been arrested
for unlawful possession.

I like to use this case to demonstrate to people that little scraps of
unimportant data can be combined to identify someone.

------
wjd2030
"Hey its not 100 bazillion % secure with ssl so why even bother"... Seriously?
The reasons presented for not doing it is only an attempt at justifying the
first part "they havent gotten around to it yet"

------
dredmorbius
Sometimes steps toward security are better than no steps toward security. If
the underlying protocol is fundamentally untrustworthy, that's another problem
as needs addressing.

------
walrus01
For small working groups that all trust each other (example: a network
engineering team at an ISP with a bastion host that everyone needs to SSH into
before accessing anything else), a really easy solution is to run an ircd that
only listens on 127.0.0.1, only allows access via properly set up
public/private key ssh shells, and have everyone keep a persistent "screen"
(or tmux) session running.

------
nsgi
Is there any reason the certificates can't be signed by a valid certificate
authority as they should be for HTTPS sites?

~~~
kbuck
Until recently, getting certificates that would work for IRC purposes has been
rather difficult. Since individual IRC servers are usually available via
multiple hostnames, it requires very expensive certificates (e.g.
someserver.example.net's IP address might also be present in the
irc.example.net, us.irc.example.net, ipv6.irc.example.net, ... DNS records).
Your options consisted of getting a "Subject Alternative Name" cert with all
of these subdomains, or getting a (very expensive) wildcard certificate. IRC
networks don't generally have much/any money to work with and this can easily
start running into hundreds of dollars per year (especially if you deploy it
properly and get one cert per server).

It's theoretically possible to deploy Let's Encrypt now for IRC servers, which
removes the cost issue. The new problems become the automated creation and
deployment of IRC server certificates. You'll most likely need to use the
DNS-01 challenge type, since most IRC servers aren't running a HTTPd and even
if they were, you couldn't guarantee that the ACME server would pick the IP of
the actual requesting server out of the "pool" records (e.g. irc.example.net).
Using DNS-01 means you'll need to write code to interface with your DNS
server, which also means securing that interaction (so other people can't
modify your DNS records and get signed certs for your domain as well).

I actually manage the (signed) certificates for one of the IRC networks I'm an
administrator for. Our two blockers for deploying Let's Encrypt are the
aforementioned challenges with DNS-01, and the fact that our software
currently validates server-to-server links using the fingerprint of each
server's individual certificate, hardcoded into the configuration file. If
we're switching certs every 3 months, we'll need some way to either distribute
certificate configuration more efficiently or we'll need to change the ircd to
verify the certificate chain instead of the fingerprint.

FWIW, our current deployment of signed certs is the "one cert to rule them
all" deployed to all servers on our network. This is definitely not ideal, but
it's by far the cheapest and easiest option prior to Let's Encrypt. All other
options we evaluated were simply way too expensive ($X,000+), extremely labor-
intensive (e.g. manually obtaining a new cert for every single server every
year/every time something changed), or both.

~~~
pfg
If dns-01 is currently a blocker for you, and you're willing to run a HTTPd on
each server, there might be another option: Redirect all challenge requests
(i.e. requests to .well-known/acme-challenge) to a common verification server
(i.e. [http://irc.example.com/.well-known/acme-
challenge/token](http://irc.example.com/.well-known/acme-challenge/token) ->
[http://verification.example.com/.well-known/acme-
challenge/t...](http://verification.example.com/.well-known/acme-
challenge/token)). That way, you can run the client on
verification.example.com and don't have to deal with distributing the
challenge token to all nodes. The verification server can then distribute the
certificates and keys to your nodes.

That's one of the recommended solutions for shared-hosting providers who don't
want to use DNS-based validation.

~~~
kbuck
DNS-01 is currently available (at least I believe it is -- I think I saw
something about its availability recently). The issue is that I will need to
write my own DNS-01 client.

Running a HTTPd on each server is a bad idea for us since it increases DDoS
attack surface area. This would essentially have the same distribution issue
that I would need to solve with a DNS-01 client as well, so either way new
code is required.

~~~
pfg
Yep, dns-01 went live in January. If your DNS server happens to support RFC
2136, take a look at lego[1] - some other provider-specific plugins for DNS
are included as well.

[1]: [https://github.com/xenolf/lego](https://github.com/xenolf/lego)

~~~
kbuck
I'm not too worried about the DNS integration; we have a fairly easily-
automatable DNS infrastructure owing to the fact that we're frequently
changing records around. I'll have to see if we can take advantage of lego to
avoid some work on our side.

------
chungy
Worse than user laziness: OFTC's servers often let their certificates expire
and hang around for months before they bother replacing them. There's usually
little choice but to tell your client to connect anyway despite all the
warnings.

