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.
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.
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.
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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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).
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.
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.
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.
"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"
73 comments
[ 3.2 ms ] story [ 133 ms ] thread- 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.
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.
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.
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)
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.
(I just tried it)
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.
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?
[1] http://arstechnica.com/tech-policy/2015/05/teen-pleads-guilt...
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.
I like to use this case to demonstrate to people that little scraps of unimportant data can be combined to identify someone.
One possible fix is, have the IRC client refuse to connect to a server if the certificate is invalid.
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.
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.
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
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.
VPNs and proxies could also obviously work, but introduce their own difficulties.
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)
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.
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.
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).
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.
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.
That's one of the recommended solutions for shared-hosting providers who don't want to use DNS-based validation.
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.
[1]: https://github.com/xenolf/lego
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.