[WireGuard] [PATCH 1/4] address:port separation uses colon, not comma

[WireGuard] [PATCH 1/4] address:port separation uses colon, not comma

[Daniel Kahn Gillmor]

This is a minor fixup to the wg(8) manpage.
---
 src/tools/wg.8 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/tools/wg.8 b/src/tools/wg.8
index c9401f0..bffe58b 100644
--- a/src/tools/wg.8
+++ b/src/tools/wg.8
@@ -128,7 +128,7 @@ CIDR masks. The catch-all \fI0.0.0.0/0\fP may be specified for matching
 all IPv4 addresses, and \fI::/0\fP may be specified for matching all
 IPv6 addresses. Required.
 .IP \(bu
-Endpoint \(em an endpoint IP or hostname, followed by a comma, and then a
+Endpoint \(em an endpoint IP or hostname, followed by a colon, and then a
 port number. Optional.
 
 .SH CONFIGURATION FILE FORMAT EXAMPLE
-- 
2.8.1

[WireGuard] [PATCH 2/4] explain "security reasons"

[Daniel Kahn Gillmor]

It's generally preferable to avoid vague "security reasons" if there
is a specific concern.

I think the reason we don't want the secret key material directly on
the command line is because of the command line's argument exposure in
the process table.

If there is another reason, i'd be happy to see a different patch
explaining it.
---
 src/tools/wg.8 | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/tools/wg.8 b/src/tools/wg.8
index bffe58b..77e9b0d 100644
--- a/src/tools/wg.8
+++ b/src/tools/wg.8
@@ -55,7 +55,8 @@ Sets configuration values for the specified \fI<interface>\fP. Multiple
 for a peer, that peer is removed, not configured. If \fIlisten-port\fP
 is not specified, the port will be automatically generated when the
 interface comes up. Both \fIprivate-key\fP and \fIpreshared-key\fP must
-be a files, for security reasons, but if you're using
+be files to avoid exposing secret material via the process table's view
+of the command line.  However, if you're using
 .BR bash (1),
 you may safely pass in a string by specifying as \fIprivate-key\fP or
 \fIpreshared-key\fP the expression: <(echo PRIVATEKEYSTRING). If
-- 
2.8.1

[WireGuard] [PATCH 3/4] Explain the optional nature of Peer.EndPoint more clearly

[Daniel Kahn Gillmor]

In the [Peer] stanza, i think the EndPoint represents an (optional)
additional constraint on where the remote peer is coming from.  If
EndPoint isn't specified, then the assumption is that anyone who can
prove posession of that public key can act as the given peer.

Clarify this in wg(8).
---
 src/tools/wg.8 | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/tools/wg.8 b/src/tools/wg.8
index 77e9b0d..ae2ff1e 100644
--- a/src/tools/wg.8
+++ b/src/tools/wg.8
@@ -130,7 +130,9 @@ all IPv4 addresses, and \fI::/0\fP may be specified for matching all
 IPv6 addresses. Required.
 .IP \(bu
 Endpoint \(em an endpoint IP or hostname, followed by a colon, and then a
-port number. Optional.
+port number.  If an Endpoint field is not provided, then any remote address
+that can prove posession of the secret corresponding to the given PublicKey
+can claim addresses in the AllowedIPs range.  Optional.
 
 .SH CONFIGURATION FILE FORMAT EXAMPLE
 This example may be used as a model for writing configuration files.
-- 
2.8.1

Re: [WireGuard] [PATCH 3/4] Explain the optional nature of Peer.EndPoint more clearly

[Jason A. Donenfeld]

I'm merging a commit with some of these suggested changes for 1,2,4.
Thanks for those. But the changes here are simply not correct.

The endpoint is simply the initial endpoint used to contact the peer.
If the peer sends legit traffic from a different endpoint, it will be
updated to that new endpoint. So, specifying an endpoint doesn't bind
traffic to that endpoint. It's simply an initial specifier of it.
Otherwise, how does traffic get started flowing?

Re: [WireGuard] [PATCH 3/4] Explain the optional nature of Peer.EndPoint more clearly

[Daniel Kahn Gillmor]

[-- Attachment #1: Type: text/plain, Size: 1896 bytes --]

On Thu 2016-06-30 22:08:08 -0400, Jason A. Donenfeld wrote:
> I'm merging a commit with some of these suggested changes for 1,2,4.
> Thanks for those.

Thanks for the update, and for your improvements to my text.

> But the changes here are simply not correct.
>
> The endpoint is simply the initial endpoint used to contact the peer.
> If the peer sends legit traffic from a different endpoint, it will be
> updated to that new endpoint. So, specifying an endpoint doesn't bind
> traffic to that endpoint. It's simply an initial specifier of it.

Great, thanks for this explanation!

> Otherwise, how does traffic get started flowing?

Well, the traffic could get flowing because the peer initiates it,
right?  A novice admin who is trying to understand whether they should
put an "Endpoint" field in their config needs to know how to make that
decision.

What do you think of the following update:

diff --git a/src/tools/wg.8 b/src/tools/wg.8
index 67b4cf7..3f255e7 100644
--- a/src/tools/wg.8
+++ b/src/tools/wg.8
@@ -130,8 +130,12 @@ to which outgoing traffic for this peer is directed. The catch-all
 \fI0.0.0.0/0\fP may be specified for matching all IPv4 addresses, and
 \fI::/0\fP may be specified for matching all IPv6 addresses. Required.
 .IP \(bu
-Endpoint \(em an endpoint IP or hostname, followed by a colon, and then a
-port number. Optional.
+Endpoint \(em an endpoint IP or hostname, followed by a colon, and
+then a port number.  This is necessary to know where to direct
+outbound traffic if no inbound traffic has been received from the
+peer.  If the peer sends authenticated traffic from a different remote
+address and/or port, it will be updated to that new information
+automatically.  Optional.
 
 .SH CONFIGURATION FILE FORMAT EXAMPLE
 This example may be used as a model for writing configuration files.




      --dkg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 948 bytes --]

Re: [WireGuard] [PATCH 3/4] Explain the optional nature of Peer.EndPoint more clearly

[Jason A. Donenfeld]

Sure, I'll try to fix that description a bit. Thanks for the suggestion.

[WireGuard] [PATCH 4/4] Clarify what Peer.AllowedIPs actually constrains

[Daniel Kahn Gillmor]

It looks to me like AllowedIPs acts as a filter for traffic sent by
the peer.  To avoid some other confused interpretation (e.g. IP
addresses that are allowed to be configured on this interface),
clarify the meaning in this configuration.

If this isn't correct, please clarify!
---
 src/tools/wg.8 | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/tools/wg.8 b/src/tools/wg.8
index ae2ff1e..6da1770 100644
--- a/src/tools/wg.8
+++ b/src/tools/wg.8
@@ -125,9 +125,10 @@ private key, and usually transmitted out of band to the author of the
 configuration file. Required.
 .IP \(bu
 AllowedIPs \(em a comma-separated list of IP (v4 or v6) addresses with
-CIDR masks. The catch-all \fI0.0.0.0/0\fP may be specified for matching
-all IPv4 addresses, and \fI::/0\fP may be specified for matching all
-IPv6 addresses. Required.
+CIDR masks that this peer is allowed to produce traffic from.  The
+catch-all \fI0.0.0.0/0\fP may be specified for matching all IPv4
+addresses, and \fI::/0\fP may be specified for matching all IPv6
+addresses. Required.
 .IP \(bu
 Endpoint \(em an endpoint IP or hostname, followed by a colon, and then a
 port number.  If an Endpoint field is not provided, then any remote address
-- 
2.8.1