Cloaks

[lbeziaud]

It would be great to add the option to define a default cloak for every users, which would replace their real hostname. If I am not mistaken, this is similar to the vhost parameter for opers (?). Being able to attribute a custom cloak to an user would be even better.

[DanielOaks]

Heyo, thanks for the issue! Implementing traditional cloaking is something I've been thinking about, definitely. It's difficult to do it in a way that preserves privacy of your original address as well as making sure people can't ban-evade, which is the main irritating factor about implementing this.

The way I'd likely go about this would be to have another cloak parameter on Client that gets populated when they join. Ban masks and similar would get checked against both the cloak and their actual hostname. However, when using a vhost then ban masks and similar should really only compare their values against that vhost.

I think doing something like this helps general day-to-day people from just seeing your IP address, and since the only action that can be affected by someone being on a banlist (or similar list) is someone sending a reply PRIVMSG/NOTICE to a message, this should help make sure people can't do something similar to that attack on Anope/Atheme where people can discover your real IP address.

I need to dig a bit deeper into this, see exactly what depends off the relevant ban/invite/etc mask lists and make sure there's no way to automagically discover someone's real address (easily) using any of those methods. After I'm reasonably happy with that, I can implement this no problem.

Doing vhosts is... planned, I'll say. But I'm not sure exactly how to do it on the admin side since I haven't digged into how that works with other systems. Maybe just creating a similar HostServ fake client like we have NS and all now.

[DanielOaks]

I'm working on this in devel+cloaks, starting with 0d3b5b2 that adds the cloaking mechanism for IPv4 addresses. Right now this adds JUST the code to actually perform the cloaking, and doesn't actually tie it into clients joining and getting cloaks applied and all.

These are the separate addresses that I need to write cloaking mechanisms for:

• IPv4 Addresses (0d3b5b2)
• IPv6 Addresses
• Hostnames

[DanielOaks]

I'm not sure exactly how I should do this, but right now I'm inspiring it off a comment in plexus4's cloaking code that outlines how it approaches this for different address types. For IPv4, this is how I'm approaching it:

IPv4 addresses can be represented as a.b.c.d, where a is the least unique part of the address and d is the most unique part.

a is unique for a given a...*, and d is unique for a given, specific a.b.c.d address. That is, if you have 1.2.3.4 and 2.3.4.4, the d part of both addresses should differ to prevent discoverability. In the same way, if you have 4.5.6.7 and 4.3.2.1 then the a part of those addresses will be the same value. This ensures chanops can properly ban dodgy people as they need to do so.

To do this, I go through something like this method:

1. Separate out the parts of the IP address into a, b, c, d.
2. Create an empty string, the key that will be hashed to create the IP octet replacement.
3. Append the current part to the key, then all less-specific parts that apply to this octet (when hashing c, the key is c+b+a, etc).
4. After all this, append a static hashing key that's used specifically for this octet of the IP address. Each octet has its own key (so for IPv4 addresses there's 4 hashing keys, etc).
5. Sha512 the key.
6. Base64 the result, lowercase it, make sure all separators are - instead of the special chars. Trim it to the first 16 characters and trim any leading/ending - characters. (Thinking about looking at base36 or something similar for this instead of base64, since we lowercase it anyway)
7. Output a.b.c.d.cloaked-net, where a is the hashed output of a... etc, and net is the netname.

This seems like it should work alright. It avoids double-hashing results like P4's impl does, since I'm iffy about double-hashing things. However, I'm not a crypto guy so I dunno how well it'll work in practice really. Here's some examples:

8.8.8.8
    -> fhzkguhmza63y8u5.gnqmmmbesue-nawp.ypq8cphg-yjvkygx.fovu8s8zps23y2ck.cloaked-toast
9.4.8.8
    -> 3d8jjp-w7llcoidc.7gvy4ronc324klje.u5rtmy09f2rbmxmc.qg-cnkwnrt66-6er.cloaked-toast
8.4.2.8
    -> fhzkguhmza63y8u5.tqnsrgz278qixhwt.taijstboi8ibu27a.ewlrvcls2nod4ikg.cloaked-toast
8.4.2.1
    -> fhzkguhmza63y8u5.tqnsrgz278qixhwt.taijstboi8ibu27a.w2-tkhrfejfcspsf.cloaked-toast

edit: Limit the above to roughly 64 chars to match traditional hostname length limits, and look at the HMAC stuff done here instead: https://gitlab.com/rizon/plexus4/merge_requests/27/diffs#dcdf904ab398035100f5fd579863f917210d606f_0_1

[DanielOaks]

As a side note, I've split the VHOST system stuff in particular into #109, have been meaning to get to that for a while but it's a liiittle lower priority than just cloaking and some other general features/enhancements.

[DanielOaks]

I've made it actually use a similar HMAC+sha256 -> base32 system as the P4 system above uses. Also shortened it so that they turn out nicer:

8.8.8.8
    -> xjtqvg6mb2.4grk5upshl.bjip2p4uup.mydoahopjs.test-cloaked
9.4.8.8
    -> 4yfdxndgf3.jpbkkfnt3g.fhbk6ukspg.5jqti37n7o.test-cloaked
8.4.2.8
    -> xjtqvg6mb2.w6j3lbv4pb.6g5gtfflr5.itzwzkd73v.test-cloaked
8.4.2.1
    -> xjtqvg6mb2.w6j3lbv4pb.6g5gtfflr5.7cudw6ngmi.test-cloaked

I think it makes sense to go ahead with this.

[bogdomania]

Quick question... if the solely reason for host mangling/cloaking is to hide one's IP address, then why not just replace the host with "users.<network_name>", and a ircd.yaml entry, to use it or not?
e.g. "users.test.oragono" instead of IP, by default...
Yes, all the users would have the same host, but the IRC ops wouldn't care... since they can see anyway who's who..
And registered users can use the vHost service, in place.

[slingamn]

Good question. I looked back over the ticket and saw a mention of (channel) ban masks, so I assume one reason is to allow channel operators (who are not privileged enough to see the underlying IPs) to ban IPs from their channels.

[slingamn]

Someone showed up in #oragono and mentioned the desire for a relatively anonymous chat system.

I'm jumping into this without much context, but rather than hashing every byte of the IPv4 address (and every two bytes of the IPv6 address) separately, I think I might prefer an approach similar to connection limiting:

1. Identify a CIDR length that is the appropriate target for anti-abuse measures, i.e., a CIDR length that is relatively likely to be associated with a single user (typically, /32 for IPv4 and /64 for IPv6)
2. Hash or encrypt that portion of the address

This errs on the side of user privacy --- for example, if alice has cloak xjtqvg6mb2.w6j3lbv4pb.6g5gtfflr5.itzwzkd73v.test-cloaked, and bob has cloak xjtqvg6mb2.w6j3lbv4pb.6g5gtfflr5.7cudw6ngmi.test-cloaked, and you know that Alice is from Zagreb, then you can deduce that Bob is probably from Zagreb as well.

[slingamn]

We might also want to see if we can avoid deanonymization via repeatedly banning different regions of the IP space, as alluded to here: https://gist.github.com/maxteufel/1e2cf7ada079c271bd3c

AllNickmasks currently returns a nickmask based on the raw IP address, if cloaking is enabled then we should not do that.

[DanielOaks]

Hmm. Something like that sounds... like it makes a lot of sense, honestly. We could probably even output the same sort of masks we do for IPv4 for IPv6 (just choosing our splits differently). Probably makes sense to preserve the order of 'hashed octets', from most specific to least specific, as that makes it a lot easier for users to ban on and is what they expect (e.g. banning *.xjtqvg6mb2.w6j3lbv4pb.6g5gtfflr5.text-cloaked rather than xjtqvg6mb2.w6j3lbv4pb.6g5gtfflr5.*.test-cloaked).

Definitely up for this, yeah.

[slingamn]

Ah, I'm suggesting a solution where we take the entire "significant portion" of the address (its CIDR) and scramble that entire portion atomically, not exposing subnet relationships within the portion anymore.

[DanielOaks]

Ah I see, that's very interesting. I could see something along those lines, yeah.

[slingamn]

Closed in #481