9 ms·
Why IRC over SSL is pointless (2009)
- Sidnicious 11y agoI 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.
- m00dy 11y agoAbsolutely, IRC over SSL is not pointless
- crystalclaw 11y agoThat, and if you can do it, it's cool.
- 15155 11y agoI 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.
- deleted 11y ago[deleted]
- raimue 11y agoMany 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 11y agoNot that CRAM-MD5 is particularly secure.
- kylek 11y agoI 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 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 http://wiki.znc.in/QAuth/Module ).
- WallWextra 11y agoYeah, it's not like twitter runs https to keep your tweets secret.
- sanqui 11y agoIf 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 11y agoThey can still do that under SSL/TLS with a MITM attack.
- mrsteveman1 11y agoThat's an active attack though, making it significantly more difficult to sniff passwords than it would be without TLS
- pfg 11y agoHow is that? Unless you're accepting self-signed certificates, that seems hard to pull off unless you're a state actor.
- deleted 11y ago[deleted]
- admax88q 11y agoI guess we can turn SSL/TLS off of your gmail then eh?
- RealityVoid 11y agoSo 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 11y agoI 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.
- blibble 11y agono, 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)
- n3t 11y agoPrivate messages (next to credentials leak) are another reason for using SSL/TLS.
- jordigh 11y agoNo, 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.
- n3t 11y agoYou are right. To be clear, I implicitly assumed that people I talk to wouldn't accept a fake certificate.
- pfg 11y agoMany 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 11y agoone 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 11y agoIs 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.
- dredmorbius 11y agoSometimes steps toward security are better than no steps toward security. If the underlying protocol is fundamentally untrustworthy, that's another problem as needs addressing.
- r1ch 11y agoYou'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 11y ago> 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_ 11y agoBecause 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-guilty-to-23-charges-of-swatting-harassing-online-game-rivals/ http://arstechnica.com/tech-policy/2015/05/teen-pleads-guilt...
- derefr 11y agoImagine 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.
- Strom 11y agoPerhaps not more than programmers/sysadmins, but there's a lot of harassment/DDoS in the gaming community.
- koenigdavidmj 11y agoThe 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 11y agoIIRC, 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.
- yzmtf2008 11y agoNo security is ever perfect, but that doesn't mean we should stop implementing all imperfect security measures.
- zxv 11y agoThe 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.
- Tehnix 11y agoSorry, 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 11y agoIRCops have a long history of being change-averse and vitriolic. This just looks like more of the same.
- Tehnix 11y agoI'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 11y agoYou're talking about people who make heavily-entrenched ideologies about minor technical distinctions into an Olympic-level contest of stubbornness and scorn.
- toast0 11y agoGet 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.
- Strom 11y agoPerfect is the enemy of good. Perhaps with a bit of added rationalization to hide laziness.
- draw_down 11y agoYeah. They're saying "bad stuff will still happen if we have SSL, so let's not do SSL". Hell of an argument.
- LamaOfRuin 11y agoNumerous 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.
- wibbler2 11y agoauthor 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 11y agoI 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 11y agoOut 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.
- torgoguys 11y agoBecause 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).
- nsgi 11y agoIs there any reason the certificates can't be signed by a valid certificate authority as they should be for HTTPS sites?
- raimue 11y agoSSL certs from existing CAs can be used for anything, not just HTTPS.
- blibble 11y agojust no clients check it, or check it properly
- raimue 11y agoBrowsers 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 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.
- kbuck 11y agoUntil 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.
- chungy 11y agoWorse 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.
- deleted 11y ago[deleted]
- kenshaw 11y agoIt'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.
- walrus01 11y agoFor 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.
- wjd2030 11y ago"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"