Closed AiyionPrime closed 3 years ago
mesh_vpn
Remote server setup for the mesh VPN.
[...]
By default the public key of a node’s VPN daemon is not added to announced respondd data; this prevents malicious ISPs from correlating VPN sessions with specific mesh nodes via public respondd data. If this is of no concern in your threat model, this behaviour can be disabled (and thus announcing the public key be enabled) by setting pubkey_privacy to false. At the moment, this option only affects fastd.
[...]
originally posted in siteconf documentation https://gluon.readthedocs.io/en/latest/user/site.html
Currently only our supernodes announce their pubkeys, as they're openly visible already.
Just got confirmation, munichs wgkex implementation sends their keys without encryption to their server.
@AiyionPrime I know... That's why I bothered lemoer several times that I wanted to luatweetnacl for encrypting the provider traffic.
From what I know it is not that privacy-critical if the public keys are publicly known as the public key is encrypted when initiating a WireGuard connection with the public key of the server. But if at some point in the future the private key of the server leaks, someone who has collected the encrypted handshakes, can decrypt them to see the public key of the peer which allows an association of IP addresses to public keys which is a privacy issue as perfect-forward-secrecy can not be guaranteed for the initial handshakes, but still for the traffic. As far as I know the content of the messages can't be decrypted once a session is established, so there is still PFS for the content.
My idea was to use luatweetnacl to encrypt the public key submission, but it just moves the problem as if the private key of the server leaks, attackers will also be possible to decrypt the submission messages. Still it's better than plaintext I think.
So you vote for deletion of the line?
@CodeFetch you do talk about encrypting the respondd path software/wireguard/public_key
, don't you?
@AiyionPrime No, but that would also be nice. I meant we should implement a proper broker in Gluon at some point. But I don't have a strong opinion on how we handle it in Freifunk Hannover, because it is not so critical I think. Now that you mention it, having a respondd encryption would be really nice. For now I wouldn't bother much if we would switch our devices to WireGuard by announcing the WireGuard public key via respondd unencrypted as the traffic is encrypted using fastd and if a national security agency wants to compromise our security, they already did using social engineering instead. It's just not best practice...
@AiyionPrime By the way do we have a PGP key for our key submission email address? I guess no. So what...
@1977er just acked via phone
@AiyionPrime By the way do we have a PGP key for our key submission email address? I guess no. So what...
Nope, not yet, but good idea.
There's a key in the siteconf, called
pubkey_privacy
. If set to false, clients in our net publish their pubkey via respondd.Currently we do set it to false, but misplaced it below fastd instead of mesh_vpn.
https://github.com/freifunkh/site/blob/547bb1d744dc23e25f5d508b5d00eb446392ed6d/site.conf#L33-L38
Is there any reason, why we wouldn't want out clients to publish it? If not I'd like to fix this.