This guy managed to use activity pub to get the real IPs of fediverse instances that are behind Cloudflare DNS. It’s about the protocol calling our real host public key to validate http signature . Is that commonly known fact and can the fediverse be improved here so that there is no such possibility?
3 Likes
Outgoing federation requests can be proxied.
It is even possible to run instance as an onion service, but in this case it will only federate with a small subset of Fediverse servers that are connected to Tor.
2 Likes
Why is this a problem? I mean Fediverse applications store their user’s IPs, see e.g. here. So a Fediverse application knows its users IPs.
Similarly, if you are a participant as an application in the Fediverse, your IP will be known to all other participants (as in applications/servers) in the Fediverse. Now, as the Fediverse is open, i.e. everybody can participate, this means the IP of every Fediverse application can be obtained by everybody.
So unless one moves the Fediverse onto something enforcing anonymity, e.g. onion servers, one will be able to obtain IPs of servers. The other option is turning the Fediverse into a closed network.
Some people prefer that their server address remains private, for security, privacy, or other reasons.
Isn’t Mastodon storing user login IPs? Some people may prefer to hide their login IPs too, but that’s not the issue discussed in the referenced article.
If “IP of every Fediverse application” means the IP of the hosting server, then this is not a true statement (see Silverpill’s comment about proxies for outgoing requests).
The “Fediverse” does not depend on knowing a server’s host address. Many servers sit behind a reverse proxy or a tunnel with different addresses than the hosting server. Of course, activity delivery requires knowing the address of those proxies or tunnels.
It looks like Mastodon stores user login addresses to detect suspicious logins. This is not a requirement for Fediverse servers and there are issues with that technique (login from different devices on different networks, network providers that assign dynamic addresses, VPN usage, etc.).
2 Likes
It may facilitate DoS attacks. Of course, you should block access from any IP addresses other than the proxy’s ones, but you still want to obfuscate the real IP address as possible because firewalls can be overwhelmed too.
Also, I think it’s arguable whether IP addresses of end users, who are typically behind NAT gateways, are comparable to those of servers.
2 Likes
I’m glad there’s discussion of both the implications of user privacy, and DoS attacks.
I’m surprised it’s taken this long for that to be brought up, but I’m happy.
I’m thankful for you bringing it forward.
This is an example of why you need a threat model. Or as it goes “security is a process and not a product.”
If your goal is to not reveal the IP address of your backend server, then you need to be methodical and analyze the entire system, not just hit a button in cloudflare.
Including image loading, key retrieval, sending data, etc.
There are ways to make that private if you need that to be private, but it requires a much deeper conversation. Someone could write a guide on that, and that would be a worthwhile exercise, but I don’t find it surprising that IP information leaks out and frankly would be surprised if there weren’t a million other ways it will leak out or could be collected.
In the meanwhile, I would ask, why do you want that? Not to say that no one will ever want it (as pointed out), but if your goal is to prevent anyone from finding your backend service that you are hosting online then specificity of your goal is good, along with other ways of achieving the same effect. Because if what you want is to not reveal your home server’s city that’s a different problem than DDoS protection.
3 Likes
why do you want that
Privacy. I guess similar reason people are using Tor browsers?
Because if what you want is to not reveal your home server’s city that’s a different problem than DDoS protection
Never said anything about DDoS. Yes, it’s a different problem.
I don’t know about other implications but personally I was only thinking about privacy and only in the particular case of it being compromised by the way ActivityPub works itself, just like described in the article. Since posting this I got to know some other ways of getting to IP of a host. I guess the post title is a bit misleading here now then.
this could be packaged into a tool that sends out a sort of “ping” packet to get an instance’s IP.
(some sort of “ActivityPing”? heh)
If it’s a “similar reason” then your solution is not cloudflare, it is Tor. You can host an AP server with an onion address. If that’s what you want, then there is a tool for that, and it isn’t cloudflare.
“Privacy” is vague and generic and means different things to different people. What is your threat model? What specific concerns do you have about which specific threats? Is trying to obscure your IP address the best way to address those threats? If it is, should you be running through Tor? Should you be running a AP server at all?
etc.
See @tesaguri’s comment.
Given that the “problem” appears to have to do with HTTP signatures, then that’s a separate domain from ActivityPub. HTTP signatures are not required for AP and, to the degree they are, the key negotiation system used is not required in the slightest.
1 Like
I self-host a Mastodon instance and I use CloudFlare tunnels as a convenient way to make my local installation flexible (can easily migrate between LAN hosts) and to provide easy subdomain setup and SSL termination for servers that I run. If I had concerns about geolocation, I wouldn’t run a server from my home or I’d at least use a proxy (or farm of proxies) for outgoing requests. I don’t need the extra protection or hassle of a TOR solution.
The DDoS risk was discussed in the article in a CloudFlare context. In my case, there’s no additional risk AFAIK since the server can only be accessed externally via CloudFlare. Having the WAN address of my home network isn’t useful since the Mastodon ports aren’t accessible through the firewall (the tunnel uses an outgoing connection to CloudFlare).
The article also mentions learning the DNS resolver address (for the WAN gateway/router, I assume). I’m curious what that means. Different machines on my LAN are configured for different (initial) DNS resolvers and those could be (and I think they are) different from the DNS server configured for the WAN gateway.
As a PSA, whatever hosting you use, I recommend searching for your server’s exposed IP address on Shodan,io. There are servers related to participants in this topic that are exposing ports they probably don’t need to expose and that are associated with out-of-date software with multiple CVEs (not self-hosted FWIW).
1 Like