Why IRC over SSL is pointless (2009) | Hacker News Reader

Why IRC over SSL is pointless (2009)

quakenet.org

57 pointsjordigh70 comments

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.

Yeah, it's not like twitter runs https to keep your tweets secret.

Absolutely, IRC over SSL is not pointless

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.

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.

Not that CRAM-MD5 is particularly secure.

I really love Quakenet's nickserv alternative/bot, Q. It offers a way to do this with a /msg Q CHALLENGE command (https://www.quakenet.org/development/challengeauth ). ZNC (a popular irc bouncer) has a nifty authentication module that utilizes it, too (http://wiki.znc.in/QAuth/Module ).

That, and if you can do it, it's cool.

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.

Perfect is the enemy of good. Perhaps with a bit of added rationalization to hide laziness.

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

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.

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

Get a certificate, and add some scary code to your stack (openssl requires a lot of attention), and seriously restrict the number of connections per second you can handle.

It's inconvenient to restart all your connections because you need to apply an openssl patch, it's when worse when all the tls handshakes increase the time to get everyone back online when you do.

it's an IRC network aimed at gamers where 98% of channels are public and free for anyone to join without any form of authentication ever.

so you'd be more accurate to say it covers 98/100 of cases, and we leave the other 2 open

the main obstacle these days is that a secure PKI deployment for a network ran by 40 different companies with no legal structure is a hard problem, not the technical challenge of putting a cert in your ircd.conf

While they are free to join the channels, I'd imagine a great deal of the users authenticate to the nickserver to avoid impersonation and to protect their nick. Without SSL, anybody on their network could potentially sniff their credentials with a lot less trouble than MITM'ing a SSL connection.

So I'd say that it's just not for the 2% that are using the secure channels, but probably for the majority of the userbase that is active for more than a couple of sessions.

QuakeNet has supported challenge response auth for more than 10 years, so this isn't a problem for anyone using that.

This a common cognitive flaw in nerds. There isn't a continuum, but a proof like step function.

(redundant)

The comment isn't dead (or at least, not anymore; can comments get resurrected from dead status)?

It would appear so. It was dead earlier, but I imagine some mod or something revived him :)

Yeah. They're saying "bad stuff will still happen if we have SSL, so let's not do SSL". Hell of an argument.

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)

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.

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.

Because you don't have a perfect solution, you don't want to do anything? Really, as mentioned many times elsewhere in this discussion, a half-assed implementation is better than none. A poor implementation would probably solve not even just a few, but a majority the issues that a "perfect" implementation would. Just disclaim the quality of the solution to the users and be done with it until you can come up with something better.

You cite the freenode mess. All true. Even with that major screwup, it protected their users to a certain extent, even with compromised keys after the fact. (The majority of snoopers aren't motivated enough to store the ciphertext).

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.

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

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

I guess we can turn SSL/TLS off of your gmail then eh?

That's an active attack though, making it significantly more difficult to sniff passwords than it would be without TLS

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.

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.

no, the reasoning is because it's more than two people, any third person can break the security by accepting an invalid cert, and the others who were careful have no way of knowing that their communications are compromised.

given IRC is mostly about channels, this renders TLS mostly pointless for IRC.

(TLS works fine with two endpoints communicating directly... mostly, it's still a kitchen sink protocol that probably needs replacing)

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.

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

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

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.

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.

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

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.

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)

Sorry for hijacking this thread to respond to a sibling comment, but I think the original author of this article may be trying to post, but is being flagged.

You can (depending on Karma, I think?) vouch for dead comments.

I just did for two of the author's comments, I don't think they should be dead at all.

1) The author states that their opinion changed somewhat

2) The author explicitly names a compromised deployment (Freenode). Haven't fact checked that, but that _seems_ like a good argument

3) The architecture of the network (random organizations sponsor servers) seems like a plausible excuse for headaches/complications as far as I'm concerned.

It seems that a mod has come along and remedied the situation. I would have vouched, but I guess I don't have that feature. I don't even have enough karma for down votes, but when I saw what seemed like a high-quality dead comment without a contentious comment history, it only felt right to speak up.

You are right. To be clear, I implicitly assumed that people I talk to wouldn't accept a fake certificate.

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.

> 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?

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

Imagine two teams in a competitive game, who each use an IRC channel to coordinate. Each team has a strong incentive to get access to the other team's channel. Programming/systems administration has no similar competitive format that would incentivize MITMing.

Some individual programmers might have a state adversary or somesuch after them—but that's one adversary attempting to MITM one user. In a competitive game with computer-savvy players, you could potentially see every player becoming an adversary against half the other users on the service.

Perhaps not more than programmers/sysadmins, but there's a lot of harassment/DDoS in the gaming community.

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.

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.

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.

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.

"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"

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.

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.

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

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.

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://verification.example.com/.well-known/acme-challenge/t...). 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.

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.

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

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.

You could have a very lightweight http server that only runs for the 30-second period of time needed to communicate with the ACME server for the certificate issue...

Many of our servers whitelist ports to harden themselves against attacks, and this whitelisting may not be done on the server itself (e.g. some of our servers do it on upstream networking equipment). We would also have to run some sort of HTTPd on ALL the servers in each round-robin being verified, which would essentially mean all our servers. DNS-01 is a much better fit for us (and our DNS server software makes it somewhat less painful).

SSL certs from existing CAs can be used for anything, not just HTTPS.

just no clients check it, or check it properly

Browsers also used to allow you to simply override invalid SSL certificates. Over time, it became more difficult and finally it is not even possible anymore when the server sent HSTS headers before.

The current draft for IRCv3.3 of the IRCv3 working group already has a draft for Strict Transport Security, see http://ircv3.net/specs/core/sts-3.3.html

We need the same culture shift in IRC clients that took place in browsers. Every IRC client should take certificate validation serious and do it properly. For that to happen, we need more SSL-enabled IRC servers and users that want to use it.

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.

Reply on news.ycombinator.com