I have been concerned for some time about the leakage of private IP addresses from the client. This occurs every time the client updates to the server, it sends the local subnet address of the host rahter than the public (NAT'ed / MASQ'ed) address.

This is useful to some users with several boxes on the same internal LAN, it helps to disambiguate them in the host listings, and indeed helps the server to do the same thing in some cases.

The IP is 'hidden' on the website, that is it is only returned to the user if the user asks for it.

On the other hand, I believe I am right in saying that the upload of the local IP address happens on every connection, and is not encrypted in any way (unless the project runs its server on https). If I am wrong, someone please let me know!

If I am right, then anyone on the route from client to server can sniff the packet and see the IP address.

Well, so what?

The issue is that crackers, like other spies, often get in by combining several small pieces of info that taken one at a time seek innocuous. One of the many simple rules that we are advised to follow in designing a firewalled LAN is not to divulge the internal addresses outside the LAN. For example, if a cracker sneaks a packet into the LAN by some other means, it is useful to him/her to be able to spoof it as coming from a genuine internal address.

This is one of the reasons that the relevant RFC says (part 3)

Indirect references to such addresses should be contained within the enterprise.

In fairness, the examples given are of indirect refs at the routing level (eg leaky routers and ISP's), but these are only examples and I'd suggest that BOINC is currently outside the spirit (at least) of the RFC.

So, what easy fixes are there?

Can this info be encrypted?

Could it be sent hashed with the user's auth, so that the server can tell IP's apart bu5t does not know the exact IP (protects against crackers from a naughty project collecting info)

Alternatively, if neither of the above are easy to implement, the user should have the option of witholding the info -- I'd suggest for backward compatibility that withheld IP's are replaced with 127.0.0.0 (clearly a dummy) or 127.0.0.1 (as if localhost, which some boxes transmit anyway).

Better, the default could be to send 127... and only release the 'true' address if specifically authorised by a new project-level preference, or by a setting that is only available in the local override XML file(s).

User/file settings could be to toggle between 127... and the true local address, or be a three way choice, localhost, local private address, or some spoof address entered directly by the user. For the astute user the last would be the best way of disambiguating his/her boxes.

R~~

The IP is 'hidden' on the website, that is it is only returned to the user if the user asks for it.

On the other hand, I believe I am right in saying that the upload of the local IP address happens on every connection, and is not encrypted in any way (unless the project runs its server on https). If I am wrong, someone please let me know!

If I am right, then anyone on the route from client to server can sniff the packet and see the IP address.

If you get to the point where a cracker can sniff the packet, you're already in deep enough trouble; my internal IP wouldn't concern me as much as other things.

In fairness, the examples given are of indirect refs at the routing level (eg leaky routers and ISP's), but these are only examples and I'd suggest that BOINC is currently outside the spirit (at least) of the RFC.

BOINC doesn't even follow stuff on the TCP RFC on its GUI RPCs. Especially "be conservative in what you send, be liberal in what you accept from others".

Can this info be encrypted?

That could be a way. But then there is always a way for the cracker to decrypt it too. What 'key' would be used in the encryption?

Could it be sent hashed with the user's auth, so that the server can tell IP's apart bu5t does not know the exact IP (protects against crackers from a naughty project collecting info)

I think server doesn't need the local IP at all, the only reason it's there is for users to see it. Server tells hosts apart using the Host ID. Having a hashed IP won't be useful for the user...

Alternatively, if neither of the above are easy to implement, the user should have the option of witholding the info -- I'd suggest for backward compatibility that withheld IP's are replaced with 127.0.0.0 (clearly a dummy) or 127.0.0.1 (as if localhost, which some boxes transmit anyway).

Now that's a better idea. If a user is paranoid enough about his local IP (and name, remember that one is sent as well) he could disable the setting. Which reminds me, the user can already tell his computers apart using the computer name, why is the local IP even needed?