KB about cloaks

[edk0]

There's an (imo) very unfortunate gist floating around that is linked in #freenode what feels like about a million times a second. I'd obviously rather people just stop linking to it, but that seems unlikely to happen, so I wonder if we should add a page in similar vein—at a minimum, we could make sure it's not full of incorrect information.

See also #135

[Fuchs]

As discussed on IRC, to make that available here as well:

I am on one hand against it, because this is one of the few things where people these days are rather good interacting with users in #freenode and giving them the correct information. On the other hand: yes, there are still people linking that horrible gist, and with what I wrote on "other people making copies of information" with all the downsides I agree on having it under freenode control.

I'd alter it a bit, though: In general I'd change the wording on what ways there are to bypass a cloak to what you should configure correctly (SASL) and avoid (DCC, clicking links etc.). Because the current information is either only partially correct (/whois) or incorrect in half the cases (SASL), and it would get rather technical to explain the reasons why.

So I'd just go with, better worded, "Cloaks are not meant to hide your IP address, that is only a side effect which doesn't work too well. A user determined to find your real IP has ways around it, so if you have good reasons to not make your own IP public, consider using a VPN, bouncer or client on a remote machine. We also recommend you (Link) configure SASL, don't click on dubious links and don't accept DCC chats or file transfers from untrusted users. Keep in mind that using some gatways, such as webchat, always exposes your IP as well."

Maybe some line could be added about exposing your IP is both a normal thing on the internet (e.g. also happens when using http) and rarely leads to problems.

[edk0]

Maybe some line could be added about exposing your IP is both a normal thing on the internet (e.g. also happens when using http) and rarely leads to problems.

:+1:. This bit is hardly ever mentioned.

[Fuchs]

I wholeheartedly disagree.

Let's start with hiding your host: if you do hide hosts by default, then it has to be done in a secure way. Current cloaks are not implemented in that way, there are various ways around them, some require no (inter)action of the targeted user at all. Thus by enabling them by default as a security feature you create a false sense of security, which is even worse than not hiding the real host.
Now if you do it in a secure way, with some one-way algorithm, you make life harder for channel operators as this system can easily be abused for evading measures such as quiets or bans. And I certainly value the ease of use for operators higher than a sense of security which is debatable. IRC is not and was not designed to be a "secure" protocol, thus it should not be used to exchange data which requires a higher level of protection. And having your IP exposed is, as per an earlier comment I wrote, normal on a wide variety of protocols, including IRC.

Encryption system: can you be a bit more verbose about that? If for authentication: PLAIN SASL and SSL/TLS is fully sufficient, more on that in a bit. If you talk about chat in general: no. IRC is first of all group chat, which makes most sane encryption systems hard up to impossible to implement for the most important use case: channels. With these you also have close to zero control who receives messages and what they do with them, some of the target channels actually provide public logs because they are support channels and it makes sense to do so. Private conversations can be encrypted, decent IRC clients have support for that. Why is a tad bit beyond me as per above (IRC not being meant to be secure), but to each their own.

Authentication: as far as I am informed and up to date, SASL in combination with SSL/TLS is sufficiently secure. I don't mind better variants being available, but I strongly oppose weaker variants to not be allowed, partially due to the target audience which contains non-tech-savy users who need to connect as easy as possible, partially due to the usual lack of client support.

DCC: As the name suggests, this is a thing between clients. The network only helps them establish an initial connection, but in general it is up to the clients if, how and when they do DCC exchanges. If users don't want it, they can disable it. But please don't disable stuff for everybody with no opt-in possibility because a small amount of users are incompetent when it comes to security. Given the usual content exchanged via P2P and the goals of freenode I also wouldn't go with that suggestion.

[edk0]

@timofonic This issue tracker is for the https://freenode.net website. I'm not quite sure how you're suggesting we improve it; we can't change freenode policy or the IRC protocol.

[Fuchs]

If cloaks aren't implemented properly... Are there some plan to fix that?

They are implemented properly.

What about making it both comfortable for the operators and secure for the users in the IRC servers? Can this be looked in the future IRCv3 protocol revisions?

I am sure they are open for suggestions. But either there is a way to have bans and quiets work independent of the cloak, or there is a way in which channel operators can see through them. The former is not possible without having a possibility to get from the cloak back to the host, so it's only a matter of time until people can be decloaked. If arbitrary channel operators can see past them, users can be decloaked (that is sort of the reason why users can be decloaked right now)

You are saying contrary arguments

No I don't. Both cases are "don't dictate users and clients what they can use and what they can't".

Do IRC wants to keep in the past?

Hopefully yes, given how well it worked and still does compared to the alternatives that came and went over time. For a "more secure" IRC protocol: read up on SILC. Feel free to use it.

You are making speculations based on certain kind of users and what the media spreads about piracy.

I didn't. I wrote about what content is mostly transferred via P2P protocols, and there are statistics on that. That's merely stating a fact.

However, all the above points except maybe the first don't seem to fit this bug report to me, as they are not about a knowledge base entry with regards to cloak. I suggest you give your input to the IRCvsomething people and ircd / services developers.

[edk0]

@timofonic I don't know if freenode has a forum for issues like yours—you could try asking staff on IRC—but I know that this issue and this tracker are focused on trying to improve the website, so let's concentrate on that here, please.

[swantzter]

Eventually you can point this discussion directly to the daemon that's underlying freenode, that's the place where this can be changed. See ircd-seven

[Mikaela]

Sometimes security by obscurity is needed

:-1: this makes me think about unrelated hiding of SSIDs which means that all devices that connect to SSID broadcast their question is that SSID anywhere near everywhere you go draining battery and making you easy to track.

Many networks provide a cloak (fake IP adress) by default and they work fine: SwiftIRC, ZJE IRC GTAXLnet, IRC-Hispano/Terra Chat, (World Wide Web Consortium aka W3C or W3)[http://irc.w3.org] IRC server, (TeraNova IRC Network)[http://www.teranova.net], (Mozilla.org IRC)[irc.mozilla.org].

I don't know what IRCds these are using, but InspIRCd cloaking is weak and easy to break like every other cloaking and all instances of Charybdis cloaking perform cloaking the exact same way so break one (done, google it) and you can uncloak every Charybdis user that there is.

There is also http://decal.sdf.org/spotfedsonline/Uncloaking-IP-Addresses-on-IRC.pdf which Anope attempts to prevent by not providing basic functionality so you would probably want freenode to move to Anope which would make most of the current users angry, especially channel operators.

[agjmills]

This seemed to have gotten away from the original point - going back to that:

I agree that some information about cloaks is necessary within the KB, but with a /groupreg slant on it. I'll work on something tonight and add a PR for it.

[swantzter]

Closed with #273