search

freifunkh / site

Freifunk Hannover specific Gluon site configuration for Firmware building.
https://hannover.freifunk.net
5 stars 5 forks source link

Wrong place for entry pubkey_privacy #54

Closed AiyionPrime closed 3 years ago

AiyionPrime commented 3 years ago

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.

AiyionPrime commented 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

AiyionPrime commented 3 years ago

Currently only our supernodes announce their pubkeys, as they're openly visible already.

https://github.com/freifunkh/site/blob/547bb1d744dc23e25f5d508b5d00eb446392ed6d/domains/template.j2#L65

AiyionPrime commented 3 years ago

Just got confirmation, munichs wgkex implementation sends their keys without encryption to their server.

CodeFetch commented 3 years ago

@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.

AiyionPrime commented 3 years ago

So you vote for deletion of the line?

AiyionPrime commented 3 years ago

@CodeFetch you do talk about encrypting the respondd path software/wireguard/public_key, don't you?

CodeFetch commented 3 years ago

@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...

CodeFetch commented 3 years ago

@AiyionPrime By the way do we have a PGP key for our key submission email address? I guess no. So what...

AiyionPrime commented 3 years ago

@1977er just acked via phone

AiyionPrime commented 3 years ago

@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.