Can Interface public key be made optional?

[dem]

I noticed the Interface public key is required by the UI. Can it be made optional since it can be calculated from the private key?

Thanks.

[rcmcdonald91]

@dem Best practice is to keep keys ephemeral and not share private keys between interfaces or peers. But I could see the value proposition here, perhaps the generate button should check if a valid private key already exists and if so, it will generate the public key only. However, if the private key field is blank, it can be assumed that the user wants to generate an entirely new key-pair.

[dem]

@vbman213 The official WireGuard apps for macOS, iOS, Windows, and Android clients don't require the Interface public key, so it might not be included in configuration files generated by VPN providers.

[rcmcdonald91]

@dem The key given to you by a provider would be the remote peer public key, not the local interface peer public key. I think a lot of the confusion could be solved by making the 'tunnel' public key field in the GUI read-only as you would only ever need to copy that value. The generate button should create a new private key (and by extension a public key), and if you save the tunnel configuration with a private key that you entered manually, it should compute the public key and display it in the public key field.

@jimp

[Griffo]

@vbman213 Some VPN providers do in fact give you the Private key in a config file. I think it's crazy and Netgate should not promote the sharing of Private keys. In fact I think they should hide it.

For example, here's a config provide by one of my VPN providers. They generate it on their website and allow you to download

[Interface]
PrivateKey = sbvLtNFzTrFxUzqXeIvSkiV5vj/gtr+ca/CkLqfsuK4=
Address = 10.64.231.58/32,fc00:bbbb:bbbb:bb01::1:e739/128
DNS = 193.138.218.74

[Peer]
PublicKey = lA7gRTmiY9IcSQGXjOEaJjvgtO76BwYJsaaNQqemMWU=
AllowedIPs = 0.0.0.0/0,::0/0
Endpoint = 185.204.1.203:51820

[yon 0]

If I manually enter the private key, the public key should be filled in automatically.

[stephenw10]

Providers send you a private key to use at your end? Like Nord, Mullvard etc?

Interesting security choice.

[rcmcdonald91]

@stephenw10 Yea that is very strange. Sort of defeats the whole point of keeping private keys private.

[jimp]

I made the public key read only and when empty and it will be populated on save (or when generating a new set of keys). Also added a copy link to copy the public key to the clipboard.

https://redmine.pfsense.org/issues/11322

We don't really encourage copying the private key, but we have to show the field since people need to set it. Hiding one field behind a button seems a bit awkward as well. Each tunnel should have its own unique keys, and we've encouraged that by having the button there to generate them as needed.

I can see the appeal of a provider wanting to generate and store client keys since it makes exporting configurations for users easier. It is most definitely not ideal from a security standpoint, but makes management easier, and for low-knowledge users it makes the whole process easier as well. Classic security vs convenience trade-off. Hopefully those providers at least also support allowing clients to submit their own public key.

[dem]

Thanks @jimp!

[dem]

@jimp As long as I'm nagging you about making things optional, how about making the CIDR values for Interface Address optional? The official WireGuard apps assume /32 and /128 when no CIDR values are provided.

Thanks.

[jimp]

I haven't tried using those values so I'm not certain if they would actually work as expected. I'd rather err on the side of caution and make users enter them.