Re: Certain private keys being mangled by wg on FreeBSD
On Tue, Jun 8, 2021 at 1:00 PM ben edmunds wrote: > By not showing this to the user to avoid confusion we actually would > create confusion in this scenario as the kernel module is performing the > clamping but the user would have no knowledge of this and leads to > issues being opened that are a non issue. The aim is not to show the > users anything about clamping unless the key needs to be clamped as it > was not clamped already. I think you are making a mistake, and introducing users to the concept of clamping will just breed confusion. > I belive it is key to remember that pfSense is not an end user > application/tool and designed to be used by admins & network engineers You made that same point on some Github bug report; it's not news to me, and it still doesn't change my point of view. Introducing excessive complexity and superfluous technical information results in problematic decisions, configurations, and decision calculuses, even for the most powerful of power users. In particular, here, I think it's only going to sow confusion and bad information to expose users to contingent details about "valid private keys" and "less valid private keys" with weird nerdy language like "unclamped". Because the fact is, any 256-bit bitstring generated from a csprng is a fine private key.
Re: Certain private keys being mangled by wg on FreeBSD
The issue here for pfSense is that the private key will be viewable just like it is within native wireguard clients in the peer config options and needs to be viewable here for admin and debug purposes. With regards to clamping and hiding this from users its tricky as it leads to red heroin issues as people debug the tunnels via showcase for example and will see a different key to which they entered in the UI. So the only logical option is to: 1) inform the admin that the key has been clamped 2) show the admin the clamped key which they can see whilst debugging. By not showing this to the user to avoid confusion we actually would create confusion in this scenario as the kernel module is performing the clamping but the user would have no knowledge of this and leads to issues being opened that are a non issue. The aim is not to show the users anything about clamping unless the key needs to be clamped as it was not clamped already. I belive it is key to remember that pfSense is not an end user application/tool and designed to be used by admins & network engineers so should be considered power users who are capable of being exposed to more information. Regards Tigger2014
Re: Certain private keys being mangled by wg on FreeBSD
On 6/7/21, Christian McDonald wrote: > One byproduct of this exercise was some code that I whipped > up that can at least detect a clamped vs unclamped key. This might > prove useful for informing a user of what is going on and thus > eliminating this class of erroneous bug report entirely. I'd recommend *not* introducing users to weird ideas like clamping or key transformation. While learning new concepts and bit masking in PHP is undoubtedly fun, those concerns shouldn't be user-facing. There's nothing wrong or dangerous about unclamped scalars passed to a proper 25519 implementation, because the implementation will clamp on input. Throwing an "X-vs-unX" distinction to users will just result in pointless fear mongering nonsense. Instead just communicate the identity of an interface by its public key, rather than its private key. If you're not willing to hide or mask private keys (which you really should), then at least deemphasize them?
Re: Certain private keys being mangled by wg on FreeBSD
Ah that makes sense. I spent some quality time playing with the bit arithmetic and I see what you mean now. Thanks for that snippet and direction. One byproduct of this exercise was some code that I whipped up that can at least detect a clamped vs unclamped key. This might prove useful for informing a user of what is going on and thus eliminating this class of erroneous bug report entirely. I'm really not sure hiding the private keys entirely in the UI is the right thing to do, especially if it seems that key generators should really be pre-clamping keys (thanks for reaching out to Mullvad btw) and not dishing out unclamped keys to begin with. On Sun, Jun 6, 2021 at 12:21 PM Jason A. Donenfeld wrote: > > On 6/6/21, Christian McDonald wrote: > > Would it not be better for wg to just fail outright instead of > > transforming a poorly generated key entered by a user, regardless of > > where the key came from? Especially if that problematic key passes the > > regex validation that was provided in another thread in this email > > list? > > No, it would not be better. There is nothing wrong with using those > keys. They're not "poorly generated" or "problematic" or dangerous in > the least. This is only a concern with your UI. > > The kernel is doing the correct thing -- clamping keys -- and > displaying an unambiguous identifier to the user: the key that it will > actually be using. > > I suspect the best thing to do for your UI would be to hide private > (and preshared) keys, and only show public keys, unless explicitly > exported into a config file. This not only reduces potential confusion > with this issue, but mitigates another potential footgun down the > line. It's also what wg(8)'s show command does by default (while > showconf will export all). -- R. Christian McDonald M: (616) 856-9291 E: rcmcdonal...@gmail.com
Re: Certain private keys being mangled by wg on FreeBSD
On 6/6/21, Christian McDonald wrote: > Would it not be better for wg to just fail outright instead of > transforming a poorly generated key entered by a user, regardless of > where the key came from? Especially if that problematic key passes the > regex validation that was provided in another thread in this email > list? No, it would not be better. There is nothing wrong with using those keys. They're not "poorly generated" or "problematic" or dangerous in the least. This is only a concern with your UI. The kernel is doing the correct thing -- clamping keys -- and displaying an unambiguous identifier to the user: the key that it will actually be using. I suspect the best thing to do for your UI would be to hide private (and preshared) keys, and only show public keys, unless explicitly exported into a config file. This not only reduces potential confusion with this issue, but mitigates another potential footgun down the line. It's also what wg(8)'s show command does by default (while showconf will export all).
Re: Certain private keys being mangled by wg on FreeBSD
Would it not be better for wg to just fail outright instead of transforming a poorly generated key entered by a user, regardless of where the key came from? Especially if that problematic key passes the regex validation that was provided in another thread in this email list? If not, what would be an appropriate solution to catch situations like this and in turn alert users? This seems like it could be a larger discussion on interoperability, especially when dealing with keys that are being generated by VPN providers. Granted, this certainly isn’t my area of expertise. Though, the behavior is just unexpected (and confusing) from an end user perspective. On Sun, Jun 6, 2021 at 11:09 AM Jason A. Donenfeld wrote: > > It looks like whatever is generating those private keys is not > clamping them. Specifically, all private keys should undergo this > transformation: > > key[0] &= 248; > key[31] = (key[31] & 127) | 64; > > In your case, your `Lm` prefix (first byte: 0x2c) is being anded with > 248, and thus turns into KG (first byte: 0x28). > > The kernel properly clamps the keys on input, though, in case > generators forget to clamp them. So what you're seeing is correct > behavior. -- R. Christian McDonald M: (616) 856-9291 E: rcmcdonal...@gmail.com
Re: Certain private keys being mangled by wg on FreeBSD
It looks like whatever is generating those private keys is not clamping them. Specifically, all private keys should undergo this transformation: key[0] &= 248; key[31] = (key[31] & 127) | 64; In your case, your `Lm` prefix (first byte: 0x2c) is being anded with 248, and thus turns into KG (first byte: 0x28). The kernel properly clamps the keys on input, though, in case generators forget to clamp them. So what you're seeing is correct behavior.
Certain private keys being mangled by wg on FreeBSD
Hi Jason, I've got an interesting case here. I've got what appears to be a few private keys provided by Mullvad that are being mangled by wg(8) on FreeBSD12.2 (pfSense 2.5.1+). Private key ```Lm0BA4UyPilHH5qnXCfr6Lw8ynecOPor88tljLy3ALk=``` ... becomes ```KG0BA4UyPilHH5qnXCfr6Lw8ynecOPor88tljLy3AHk=``` on wg showconf another example is ```zQwldrChCYP3P2fZeTtHmj3c/88hxM+TaLIq1mJ28ZY=``` turns into ```yAwldrChCYP3P2fZeTtHmj3c/88hxM+TaLIq1mJ28VY=``` I must have just gotten lucky with the keys Mullvad provided to me, as those worked and continue to work fine for me. ref : https://github.com/theonemcdonald/pfSense-pkg-WireGuard/issues/105 Best, -- R. Christian McDonald E: rcmcdonal...@gmail.com