Development discussion of WireGuard
 help / color / mirror / Atom feed
* Certain private keys being mangled by wg on FreeBSD
@ 2021-06-06 14:27 Christian McDonald
  2021-06-06 15:09 ` Jason A. Donenfeld
  0 siblings, 1 reply; 8+ messages in thread
From: Christian McDonald @ 2021-06-06 14:27 UTC (permalink / raw)
  To: Jason A. Donenfeld; +Cc: wireguard

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: rcmcdonald91@gmail.com

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Certain private keys being mangled by wg on FreeBSD
  2021-06-06 14:27 Certain private keys being mangled by wg on FreeBSD Christian McDonald
@ 2021-06-06 15:09 ` Jason A. Donenfeld
  2021-06-06 15:59   ` Christian McDonald
  0 siblings, 1 reply; 8+ messages in thread
From: Jason A. Donenfeld @ 2021-06-06 15:09 UTC (permalink / raw)
  To: Christian McDonald; +Cc: WireGuard mailing list

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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Certain private keys being mangled by wg on FreeBSD
  2021-06-06 15:09 ` Jason A. Donenfeld
@ 2021-06-06 15:59   ` Christian McDonald
  2021-06-06 16:21     ` Jason A. Donenfeld
  0 siblings, 1 reply; 8+ messages in thread
From: Christian McDonald @ 2021-06-06 15:59 UTC (permalink / raw)
  To: Jason A. Donenfeld; +Cc: WireGuard mailing list

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 <Jason@zx2c4.com> 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: rcmcdonald91@gmail.com

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Certain private keys being mangled by wg on FreeBSD
  2021-06-06 15:59   ` Christian McDonald
@ 2021-06-06 16:21     ` Jason A. Donenfeld
  2021-06-07 11:05       ` Christian McDonald
  0 siblings, 1 reply; 8+ messages in thread
From: Jason A. Donenfeld @ 2021-06-06 16:21 UTC (permalink / raw)
  To: Christian McDonald; +Cc: WireGuard mailing list

On 6/6/21, Christian McDonald <rcmcdonald91@gmail.com> 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).

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Certain private keys being mangled by wg on FreeBSD
  2021-06-06 16:21     ` Jason A. Donenfeld
@ 2021-06-07 11:05       ` Christian McDonald
  2021-06-07 12:52         ` Jason A. Donenfeld
  0 siblings, 1 reply; 8+ messages in thread
From: Christian McDonald @ 2021-06-07 11:05 UTC (permalink / raw)
  To: Jason A. Donenfeld; +Cc: WireGuard mailing list

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 <Jason@zx2c4.com> wrote:
>
> On 6/6/21, Christian McDonald <rcmcdonald91@gmail.com> 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: rcmcdonald91@gmail.com

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Certain private keys being mangled by wg on FreeBSD
  2021-06-07 11:05       ` Christian McDonald
@ 2021-06-07 12:52         ` Jason A. Donenfeld
  2021-06-07 19:17           ` ben edmunds
  0 siblings, 1 reply; 8+ messages in thread
From: Jason A. Donenfeld @ 2021-06-07 12:52 UTC (permalink / raw)
  To: Christian McDonald; +Cc: WireGuard mailing list

On 6/7/21, Christian McDonald <rcmcdonald91@gmail.com> 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?

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Certain private keys being mangled by wg on FreeBSD
  2021-06-07 12:52         ` Jason A. Donenfeld
@ 2021-06-07 19:17           ` ben edmunds
  2021-06-08 13:20             ` Jason A. Donenfeld
  0 siblings, 1 reply; 8+ messages in thread
From: ben edmunds @ 2021-06-07 19:17 UTC (permalink / raw)
  To: wireguard

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



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Certain private keys being mangled by wg on FreeBSD
  2021-06-07 19:17           ` ben edmunds
@ 2021-06-08 13:20             ` Jason A. Donenfeld
  0 siblings, 0 replies; 8+ messages in thread
From: Jason A. Donenfeld @ 2021-06-08 13:20 UTC (permalink / raw)
  To: ben edmunds; +Cc: WireGuard mailing list

On Tue, Jun 8, 2021 at 1:00 PM ben edmunds <tigger2014g@gmail.com> 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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2021-06-08 13:20 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-06 14:27 Certain private keys being mangled by wg on FreeBSD Christian McDonald
2021-06-06 15:09 ` Jason A. Donenfeld
2021-06-06 15:59   ` Christian McDonald
2021-06-06 16:21     ` Jason A. Donenfeld
2021-06-07 11:05       ` Christian McDonald
2021-06-07 12:52         ` Jason A. Donenfeld
2021-06-07 19:17           ` ben edmunds
2021-06-08 13:20             ` Jason A. Donenfeld

Development discussion of WireGuard

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/wireguard/0 wireguard/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 wireguard wireguard/ http://inbox.vuxu.org/wireguard \
		wireguard@lists.zx2c4.com
	public-inbox-index wireguard

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.wireguard


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git