WireGuard Archive on lore.kernel.org
 help / Atom feed
* WireGuard deployment considerations for improved privacy
@ 2019-01-14 10:23 Fredrik Strömberg
  2019-01-14 12:53 ` Matthias Urlichs
       [not found] ` <CAOAVeL0Hv343JWU1m06p-WaspsNFpB6Tnw6EdYr=LdMVQLM0AQ@mail.gmail.com>
  0 siblings, 2 replies; 6+ messages in thread
From: Fredrik Strömberg @ 2019-01-14 10:23 UTC (permalink / raw)
  To: WireGuard mailing list

Greetings fellow WireGuard users,

I represent Mullvad, a privacy-focused VPN provider. We and some
others think there are currently two aspects of WireGuard that make
its deployment in a privacy-focused setting a bit challenging. The
goal of this email is to present current thoughts on the issues and
facilitate discussion. It contains language and ideas from others who
have commented on this elsewhere. Thank you. Feel free to make
yourselves known. Any errors are mine however.

The two issues are:
* WireGuard does not offer identity hiding forward secrecy
* WireGuard does not offer dynamic IP address assignment

Together with other interested parties I hope to arrive at a good
solution to these issues, which can be adopted by any apps that want
to offer privacy. The time to do this is now, before WireGuard reaches
massive adoption and multiple incompatible hacks are made.

You might care about this if you:
* Run a VPN proxy/server where you or your users care about privacy
* Use a commercial VPN service
* Provide a commercial VPN service


-WireGuard does not offer identity hiding forward secrecy-

--The problem--
In the context of a VPN service the peers can be viewed as Client(s)
and Server. A key compromise of the VPN server's static private key
makes an attacker able to decrypt recorded handshakes and thus
correlate all connections made using any given client static key, i.e.
VPN user. Here's how:

1. An attacker records encrypted traffic flows to/from a VPN server.

2. Time passes. The attacker gets hold of the VPN server's static
private key, by raiding a data centre, breaking into a VPN server
host, or something else.

3. The attacker uses the VPN server static private key to decrypt the
recorded handshakes, revealing client static pubkeys.

4. The attacker uses client static pubkeys to correlate traffic flows
with particular users including possibly linking individuals to client
pubkeys through other data sources, e.g. VPN provider business records
or other IP address metadata.

--Nuances--
A successful attack requires both the capability to record traffic
flows as well as to compromise the server key. Still, the lack of
identity hiding forward secrecy means WireGuard offers worse privacy
than e.g. OpenVPN in this respect.

It should be noted that both WireGuard and OpenVPN send tunnel session
IDs in the clear. A user that roams between networks will probably
leak the session ID between them. On the other hand, a user that
explicitly disconnects on network 1 and reconnects the VPN tunnel on
network 2 will have a new tunnel session ID that is not linkable to
the first one. In this case OpenVPN (assuming user/pass auth and not
client-cert) will have identity hiding forward secrecy, and WireGuard
does not.

If a WireGuard user application connects with a new pubkey every time
a new tunnel is established, it will provide the same identity hiding
properties as OpenVPN. However depending on the position of the
surveillance equipment and the method of key compromise neither
OpenVPN nor WireGuard would be sufficient protection. That's
out-of-scope for this discussion however.

--Proposed mitigation--
In order to get identity hiding forward secrecy the suggestion is to
have the client change its static pubkey often in order to de-link VPN
sessions, in the event of a compromise of the server's static private
key. “Often” might be a time limit, a bandwidth limit, and events like
reboot of the system, the app, new WiFi, new DHCP lease, or explicitly
by the user. To provide the same properties as OpenVPN it should be
enough to change pubkey every time the user does a connect/disconnect.

This should probably be a functionality on top of WireGuard, which
should stay minimal. It should be possible for clients to register new
static pubkeys with the VPN service and to ask it to forget about old
pubkeys. One current idea is to define a service on top of WireGuard
running as a daemon on both client and server, communicating over a
WireGuard session.


-WireGuard does not offer dynamic IP address assignment-

--The problem--
The tunnel-internal IP address can leak through WebRTC and perhaps
other ways. A long term IP address assignment could enable a website
that exfiltrates the IP address to use it as a unique identifier
between website visits, even if the user has cleared all browsing
data. There are other ways of doing this.

A perhaps more serious consequence of static assignment is that the IP
address is stored linked to a user's static public key, which in turn
might be linked to a user’s personal identity through the server’s
authentication system. If the attacker learns the IP address as well
as gains access to the user database, it might be able to link the IP
address to a person.

In a commercial VPN service setup, the IP address and thus its static
public key are probably linked to a customer account, and to payment
information. If this is the case, an attacker might be able to
identify the user. There are various mitigations and hacks one could
do as an operator to prevent this. Regardless, an approach to
ephemeral IP addresses that is accepted as standard would be
preferable.

--Proposed mitigation--
Make it possible for clients to request a dynamically assigned IP
address from the VPN server. One idea is to define a service on top of
WireGuard running as a daemon on both client and server, communicating
over a WireGuard session. The client would need a statically assigned
link-local IPv6 address and use that to communicate with the
server-side daemon, which then assigns an IP address dynamically.


-What's been done already?-

An effort has already started regarding the dynamic IP addresses. Read
the following for more info:
https://www.wireguard.com/todo/
https://docs.google.com/document/d/11RJDDrdIsnGivz8xP5NsOteHdviuV4jfNG1CSl0q8cY/edit
https://git.zx2c4.com/wg-dynamic

One issue with an in-tunnel daemon is authentication of client and
server. It’s possible the client side of the WireGuard tunnel is
actually a router for many more clients, who probably shouldn’t be
authorized to renegotiate the router’s dynamic IP address or pubkey.
An alternative to an in-tunnel daemon would be to use peer-addressed
datagrams for control messages instead, but that introduces other
complexities as mentioned in the documents above.


-Summary-
A privacy-focused deployment of WireGuard should provide identity
hiding forward secrecy and short-term dynamic IP address assignment.
WireGuard provides neither, since it's out-of-scope for the project's
goals, for good reasons. One solution would be to define a service
that communicates over a WireGuard tunnel. The same service could
provide API calls for both needs, as well as other things.

Finally, it would be good if the mechanism and protocol remained the
same regardless of if one was connecting to a lone WireGuard server,
or to a WireGuard server in a network of many, such as a large VPN
service provider. I for one expect WireGuard to become the standard
VPN protocol for VPN services within a few years, and that they will
continue to grow until then. To my knowledge the largest ones today
run almost 10,000 servers.


Thank you for your time.

Best regards,
Fredrik Stromberg
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

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

* Re: WireGuard deployment considerations for improved privacy
  2019-01-14 10:23 WireGuard deployment considerations for improved privacy Fredrik Strömberg
@ 2019-01-14 12:53 ` Matthias Urlichs
       [not found] ` <CAOAVeL0Hv343JWU1m06p-WaspsNFpB6Tnw6EdYr=LdMVQLM0AQ@mail.gmail.com>
  1 sibling, 0 replies; 6+ messages in thread
From: Matthias Urlichs @ 2019-01-14 12:53 UTC (permalink / raw)
  To: wireguard

[-- Attachment #1.1.1: Type: text/plain, Size: 1027 bytes --]

Hi,
> 3. The attacker uses the VPN server static private key to decrypt the
> recorded handshakes, revealing client static pubkeys.

Create a service that sets a new temporary pubkey. Call it *before*
connecting with WG.

Switching during a connection doesn't help much IMHO, because if you
have recorded WG traffic you probably can correlate by IP address.

> Make it possible for clients to request a dynamically assigned IP
> address from the VPN server.

Use the above service to also assign a new dynamic IP address.

Both can and probably should be done at some arbitrary time, thus
decoupling this step from using the WG connection.

I haven't seen a compelling argument for augmenting the WG protocol
(and/or its in-kernel implementation) with support for this. However,
there may be a case for creating a standardized userspace
protocol+library to implement this and possibly a few other higher-level
features, so that people don't need to reinvent their wheels.

-- 
-- Matthias Urlichs



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

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

* Re: WireGuard deployment considerations for improved privacy
       [not found] ` <CAOAVeL0Hv343JWU1m06p-WaspsNFpB6Tnw6EdYr=LdMVQLM0AQ@mail.gmail.com>
@ 2019-01-15 10:56   ` Fredrik Strömberg
       [not found]     ` <CAOAVeL32OBbhyzrJ-z6nLYMUUJsOFOSVNpbo4wdQN3zV=6yndw@mail.gmail.com>
  0 siblings, 1 reply; 6+ messages in thread
From: Fredrik Strömberg @ 2019-01-15 10:56 UTC (permalink / raw)
  To: WireGuard mailing list

On Mon, Jan 14, 2019 at 1:05 PM Henning Reich <henningreich@gmail.com> wrote:
>
> 3. The attacker uses the VPN server static private key to decrypt the
> recorded handshakes, revealing client static pubkeys.
>
> I think, this is not possible.
> WG use DH for Key-Exchange as other VPNs do (like OpenVPN). Only with recorded traffic, you have no information about the used private DH-Keys --> You still can't decrypt the handshake
> See https://www.wireguard.com/protocol/#key-exchange-and-data-packets
>

First of all, thank you for being the first to reply.

It is true that WireGuard uses ECDH for key exchange, but it does so
in a way that doesn't offer identity hiding forward secrecy.

The page you linked says "WireGuard uses the Noise_IK handshake from
Noise". You can read more about that handshake on this site:
http://www.noiseprotocol.org/noise.html

On the page above under the section "7.7. Payload security properties"
you can read the following for Noise_IK:
"""
Encryption to a known recipient, forward secrecy for sender compromise
only, vulnerable to replay. This payload is encrypted based only on
DHs involving the recipient's static key pair. If the recipient's
static private key is compromised, even at a later date, this payload
can be decrypted. This message can also be replayed, since there's no
ephemeral contribution from the recipient.
"""

If you want to dig into this yourself have a look at the WireGuard
paper. Read section 5.4.2 and read through how msg.static is
calculated.

As an aside, I think it's entirely reasonable at the moment to use
Noise_IK. Identity hiding forward secrecy would require another
round-trip, assuming no experimental crypto. It would increase latency
on setup, decrease DoS protection, and, most importantly in my
opinion, increase the complexity of the protocol state machine. I view
WireGuard as a very secure and trustworthy building block on which to
build. It just so happens that the use case I'm most interested in
introduces some deployment concerns.

Cheers,
Fredrik
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

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

* Re: WireGuard deployment considerations for improved privacy
       [not found]     ` <CAOAVeL32OBbhyzrJ-z6nLYMUUJsOFOSVNpbo4wdQN3zV=6yndw@mail.gmail.com>
@ 2019-01-15 14:27       ` Fredrik Strömberg
  2019-01-16 16:34         ` Jose Marinez
  0 siblings, 1 reply; 6+ messages in thread
From: Fredrik Strömberg @ 2019-01-15 14:27 UTC (permalink / raw)
  To: Henning Reich; +Cc: WireGuard mailing list

On Tue, Jan 15, 2019 at 1:05 PM Henning Reich <henningreich@gmail.com> wrote:
>
> Thank for your reply too,
>
> I "use" this list and conversation to get a bit more information about crypto at all (it looks like I need that :-)
>
I see. When I wanted to learn more about network security protocols I
read the RFC for TLS from start to finish a few times. Every time I
didn't understand a word or concept I looked it up on Wikipedia, often
reading the entire article on that concept. In your case maybe read
the WireGuard paper a few times and reference Wikipedia. That's a good
start.

> I try to explain how I understood the problem, and anybdoy can tell me, where I have make a mistake :-)
> From https://www.wireguard.com/protocol/#key-exchange-and-data-packets
> the initiation message and the response use
> initiator.ephemeral_private = DH_GENERATE() and
> responder.ephemeral_private = DH_GENERATE()
>
Correct. Although to be exact DH-Generate returns a keypair (private, public).

> This means (I think), that for every new connection, a new DH-Key is generated. For me (not a programmer) it looks like all other private informations in the messages a encrypted/hashed with values derived from this DH-Key.

Almost. It uses Diffie-Hellman with the ephemeral private key as one component.

In the first message, msg.static is encrypted using a key derived from
DH of the Initiator's ephemeral private key, and the Responder's
static public key (which is already known to Initiator). The first
message also includes the field msg.ephemeral which contains the
Initiator's ephemeral public key, transmitted in the clear.

When the message is received by the Responder, she is able to decrypt
msg.static and learn the Initiator's static public key. You might ask
how that is possible when she doesn't have the Initiator's ephemeral
private key. The reason is that she can derive the correct encryption
key using the Initiator's ephemeral public key, previously transmitted
in the clear, and her (the Responder) static private key.

ECDH ( Initiator's ephemeral private key, Responder's static pubkey )
=
ECDH ( Initiator's ephemeral public key, Responder's static private key )

> Because both site knows the other static key, I would look in the "XX" Row, and there is your quoted destination proberty not exisintg.
>
WireGuard uses Noise_IK, not Noise_XX.

> It's probably possible that I ignore some cryptographic basics or misunderstood same facts. So I hope somebody takes the time and give me some more hints. Thanks
>
No worries. We're all learning something. If you want to learn more
about cryptographic protocols just put in the time. And when you don't
understand something, or suspect that you are wrong, read the whole
thing again. That's what I did :)

Cheers,
Fredrik
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

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

* Re: WireGuard deployment considerations for improved privacy
  2019-01-15 14:27       ` Fredrik Strömberg
@ 2019-01-16 16:34         ` Jose Marinez
  2019-01-18  8:19           ` Fredrik Strömberg
  0 siblings, 1 reply; 6+ messages in thread
From: Jose Marinez @ 2019-01-16 16:34 UTC (permalink / raw)
  To: Fredrik Strömberg, Henning Reich; +Cc: WireGuard mailing list

[-- Attachment #1.1: Type: text/plain, Size: 4719 bytes --]

Hi Fredrik,
I appreciate this proposition as well as your summary for the current state of Wireguard for this particular case. I agree with you wholeheartedly that before the mass adoption of Wireguard happens these use cases should be addressed properly. I'd love to hear what Jason has to say about this and what he proposes.
I too have been thinking about all the edge cases for Wireguard. My approach has been to look at it from a penetration test perspective. Reality is that Wireguard doesn't live in isolation. As a system - hardware, OS and all it's settings + Wireguard - connected to the Internet and a user(s) presents many hostile dynamics.
Ultimately, whatever solution emerges needs to supplement the goals and features of Wireguard, otherwise it deafts the purpose. 
Would it make sense to create a small group to tackle this and other use cases - scaling, simplicity, etc? On my end, I'm not a cryptologist, but I can write software that would test the security of any system. I'm sure other members of this list have a ton of skills and experience to bring to this. 
Here's a list of things I'd like to see and would be willing to participate/create if they don't exist yet:
1. A honeypot server with public logs for a small team to gather and record real-time traffic as an authorized user of the server - root.2. A test suite that goes through all the domain specific scenarios from the results of #1 and provides a verification at the end once completed.3. Provide feedback from all this back to Jason for enhancements, etc. in upstream Wireguard.
Feel free to reach out off-list.

Thanks,Jose

On Tuesday, January 15, 2019, 9:27 AM, Fredrik Strömberg <stromberg@mullvad.net> wrote:

On Tue, Jan 15, 2019 at 1:05 PM Henning Reich <henningreich@gmail.com> wrote:
>
> Thank for your reply too,
>
> I "use" this list and conversation to get a bit more information about crypto at all (it looks like I need that :-)
>
I see. When I wanted to learn more about network security protocols I
read the RFC for TLS from start to finish a few times. Every time I
didn't understand a word or concept I looked it up on Wikipedia, often
reading the entire article on that concept. In your case maybe read
the WireGuard paper a few times and reference Wikipedia. That's a good
start.

> I try to explain how I understood the problem, and anybdoy can tell me, where I have make a mistake :-)
> From https://www.wireguard.com/protocol/#key-exchange-and-data-packets
> the initiation message and the response use
> initiator.ephemeral_private = DH_GENERATE() and
> responder.ephemeral_private = DH_GENERATE()
>
Correct. Although to be exact DH-Generate returns a keypair (private, public).

> This means (I think), that for every new connection, a new DH-Key is generated. For me (not a programmer) it looks like all other private informations in the messages a encrypted/hashed with values derived from this DH-Key.

Almost. It uses Diffie-Hellman with the ephemeral private key as one component.

In the first message, msg.static is encrypted using a key derived from
DH of the Initiator's ephemeral private key, and the Responder's
static public key (which is already known to Initiator). The first
message also includes the field msg.ephemeral which contains the
Initiator's ephemeral public key, transmitted in the clear.

When the message is received by the Responder, she is able to decrypt
msg.static and learn the Initiator's static public key. You might ask
how that is possible when she doesn't have the Initiator's ephemeral
private key. The reason is that she can derive the correct encryption
key using the Initiator's ephemeral public key, previously transmitted
in the clear, and her (the Responder) static private key.

ECDH ( Initiator's ephemeral private key, Responder's static pubkey )
=
ECDH ( Initiator's ephemeral public key, Responder's static private key )

> Because both site knows the other static key, I would look in the "XX" Row, and there is your quoted destination proberty not exisintg.
>
WireGuard uses Noise_IK, not Noise_XX.

> It's probably possible that I ignore some cryptographic basics or misunderstood same facts. So I hope somebody takes the time and give me some more hints. Thanks
>
No worries. We're all learning something. If you want to learn more
about cryptographic protocols just put in the time. And when you don't
understand something, or suspect that you are wrong, read the whole
thing again. That's what I did :)

Cheers,
Fredrik
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard




[-- Attachment #1.2: Type: text/html, Size: 7180 bytes --]

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office"><head><!--[if gte mso 9]><xml><o:OfficeDocumentSettings><o:AllowPNG/><o:PixelsPerInch>96</o:PixelsPerInch></o:OfficeDocumentSettings></xml><![endif]--></head><body>
Hi Fredrik,<div><br></div><div>I appreciate this proposition as well as your summary for the current state of Wireguard for this particular case. I agree with you wholeheartedly that before the mass adoption of Wireguard happens these use cases should be addressed properly. I'd love to hear what Jason has to say about this and what he proposes.</div><div><br></div><div>I too have been thinking about all the edge cases for Wireguard. My approach has been to look at it from a penetration test perspective. Reality is that Wireguard doesn't live in isolation. As a system - hardware, OS and all it's settings + Wireguard - connected to the Internet and a user(s) presents many hostile dynamics.</div><div><br></div><div>Ultimately, whatever solution emerges needs to supplement the goals and features of Wireguard, otherwise it deafts the purpose.&nbsp;</div><div><br></div><div>Would it make sense to create a small group to tackle this and other use cases - scaling, simplicity, etc? On my end, I'm not a cryptologist, but I can write software that would test the security of any system. I'm sure other members of this list have a ton of skills and experience to bring to this.&nbsp;</div><div><br></div><div>Here's a list of things I'd like to see and would be willing to participate/create if they don't exist yet:</div><div><br></div><div>1. A honeypot server with public logs for a small team to gather and record real-time traffic as an authorized user of the server - root.</div><div>2. A test suite that goes through all the domain specific scenarios from the results of #1 and provides a verification at the end once completed.</div><div>3. Provide feedback from all this back to Jason for enhancements, etc. in upstream Wireguard.</div><div><br></div><div>Feel free to reach out off-list.<br><br>Thanks,<div>Jose</div><br><p class="yahoo-quoted-begin" style="font-size: 15px; color: #715FFA; padding-top: 15px; margin-top: 0">On Tuesday, January 15, 2019, 9:27 AM, Fredrik Strömberg &lt;stromberg@mullvad.net&gt; wrote:</p><blockquote class="iosymail"><div dir="ltr">On Tue, Jan 15, 2019 at 1:05 PM Henning Reich &lt;<a ymailto="mailto:henningreich@gmail.com" href="mailto:henningreich@gmail.com">henningreich@gmail.com</a>&gt; wrote:<br></div><div dir="ltr">&gt;<br></div><div dir="ltr">&gt; Thank for your reply too,<br></div><div dir="ltr">&gt;<br></div><div dir="ltr">&gt; I "use" this list and conversation to get a bit more information about crypto at all (it looks like I need that :-)<br></div><div dir="ltr">&gt;<br></div><div dir="ltr">I see. When I wanted to learn more about network security protocols I<br></div><div dir="ltr">read the RFC for TLS from start to finish a few times. Every time I<br></div><div dir="ltr">didn't understand a word or concept I looked it up on Wikipedia, often<br></div><div dir="ltr">reading the entire article on that concept. In your case maybe read<br></div><div dir="ltr">the WireGuard paper a few times and reference Wikipedia. That's a good<br></div><div dir="ltr">start.<br></div><div dir="ltr"><br></div><div dir="ltr">&gt; I try to explain how I understood the problem, and anybdoy can tell me, where I have make a mistake :-)<br></div><div dir="ltr">&gt; From <a href="https://www.wireguard.com/protocol/#key-exchange-and-data-packets" target="_blank">https://www.wireguard.com/protocol/#key-exchange-and-data-packets</a><br></div><div dir="ltr">&gt; the initiation message and the response use<br></div><div dir="ltr">&gt; initiator.ephemeral_private = DH_GENERATE() and<br></div><div dir="ltr">&gt; responder.ephemeral_private = DH_GENERATE()<br></div><div dir="ltr">&gt;<br></div><div dir="ltr">Correct. Although to be exact DH-Generate returns a keypair (private, public).<br></div><div dir="ltr"><br></div><div dir="ltr">&gt; This means (I think), that for every new connection, a new DH-Key is generated. For me (not a programmer) it looks like all other private informations in the messages a encrypted/hashed with values derived from this DH-Key.<br></div><div dir="ltr"><br></div><div dir="ltr">Almost. It uses Diffie-Hellman with the ephemeral private key as one component.<br></div><div dir="ltr"><br></div><div dir="ltr">In the first message, msg.static is encrypted using a key derived from<br></div><div dir="ltr">DH of the Initiator's ephemeral private key, and the Responder's<br></div><div dir="ltr">static public key (which is already known to Initiator). The first<br></div><div dir="ltr">message also includes the field msg.ephemeral which contains the<br></div><div dir="ltr">Initiator's ephemeral public key, transmitted in the clear.<br></div><div dir="ltr"><br></div><div dir="ltr">When the message is received by the Responder, she is able to decrypt<br></div><div dir="ltr">msg.static and learn the Initiator's static public key. You might ask<br></div><div dir="ltr">how that is possible when she doesn't have the Initiator's ephemeral<br></div><div dir="ltr">private key. The reason is that she can derive the correct encryption<br></div><div dir="ltr">key using the Initiator's ephemeral public key, previously transmitted<br></div><div dir="ltr">in the clear, and her (the Responder) static private key.<br></div><div dir="ltr"><br></div><div dir="ltr">ECDH ( Initiator's ephemeral private key, Responder's static pubkey )<br></div><div dir="ltr">=<br></div><div dir="ltr">ECDH ( Initiator's ephemeral public key, Responder's static private key )<br></div><div dir="ltr"><br></div><div dir="ltr">&gt; Because both site knows the other static key, I would look in the "XX" Row, and there is your quoted destination proberty not exisintg.<br></div><div dir="ltr">&gt;<br></div><div dir="ltr">WireGuard uses Noise_IK, not Noise_XX.<br></div><div dir="ltr"><br></div><div dir="ltr">&gt; It's probably possible that I ignore some cryptographic basics or misunderstood same facts. So I hope somebody takes the time and give me some more hints. Thanks<br></div><div dir="ltr">&gt;<br></div><div dir="ltr">No worries. We're all learning something. If you want to learn more<br></div><div dir="ltr">about cryptographic protocols just put in the time. And when you don't<br></div><div dir="ltr">understand something, or suspect that you are wrong, read the whole<br></div><div dir="ltr">thing again. That's what I did :)<br></div><div dir="ltr"><br></div><div dir="ltr">Cheers,<br></div><div dir="ltr">Fredrik<br></div><div dir="ltr">_______________________________________________<br></div><div dir="ltr">WireGuard mailing list<br></div><div dir="ltr"><a ymailto="mailto:WireGuard@lists.zx2c4.com" href="mailto:WireGuard@lists.zx2c4.com">WireGuard@lists.zx2c4.com</a><br></div><div dir="ltr"><a href="https://lists.zx2c4.com/mailman/listinfo/wireguard" target="_blank">https://lists.zx2c4.com/mailman/listinfo/wireguard</a><br></div><blockquote></blockquote></blockquote></div>
</body></html>

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

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

* Re: WireGuard deployment considerations for improved privacy
  2019-01-16 16:34         ` Jose Marinez
@ 2019-01-18  8:19           ` Fredrik Strömberg
  0 siblings, 0 replies; 6+ messages in thread
From: Fredrik Strömberg @ 2019-01-18  8:19 UTC (permalink / raw)
  To: WireGuard mailing list

On Wed, Jan 16, 2019 at 5:34 PM Jose Marinez <jedi_papi@yahoo.com> wrote:
> I appreciate this proposition as well as your summary for the current state of Wireguard for this particular case. I agree with you wholeheartedly that before the mass adoption of Wireguard happens these use cases should be addressed properly. I'd love to hear what Jason has to say about this and what he proposes.
>
I agree. Let's see what Jason says.

> I too have been thinking about all the edge cases for Wireguard. My approach has been to look at it from a penetration test perspective. Reality is that Wireguard doesn't live in isolation. As a system - hardware, OS and all it's settings + Wireguard - connected to the Internet and a user(s) presents many hostile dynamics.
>
> Ultimately, whatever solution emerges needs to supplement the goals and features of Wireguard, otherwise it deafts the purpose.
>
> Would it make sense to create a small group to tackle this and other use cases - scaling, simplicity, etc? On my end, I'm not a cryptologist, but I can write software that would test the security of any system. I'm sure other members of this list have a ton of skills and experience to bring to this.
>
> Here's a list of things I'd like to see and would be willing to participate/create if they don't exist yet:
>
> 1. A honeypot server with public logs for a small team to gather and record real-time traffic as an authorized user of the server - root.
> 2. A test suite that goes through all the domain specific scenarios from the results of #1 and provides a verification at the end once completed.
> 3. Provide feedback from all this back to Jason for enhancements, etc. in upstream Wireguard.
>
Honestly I'm very focused on the two issues I brought up. Those are
the most important things we don't see a clear solution to yet.

Well, we'd also like userspace to be notified of new handshakes, and
be able to reply to the kernel module whether it's a known pubkey or
not. Or something. That's a different discussion though.

Cheers,
Fredrik
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

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

end of thread, back to index

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-14 10:23 WireGuard deployment considerations for improved privacy Fredrik Strömberg
2019-01-14 12:53 ` Matthias Urlichs
     [not found] ` <CAOAVeL0Hv343JWU1m06p-WaspsNFpB6Tnw6EdYr=LdMVQLM0AQ@mail.gmail.com>
2019-01-15 10:56   ` Fredrik Strömberg
     [not found]     ` <CAOAVeL32OBbhyzrJ-z6nLYMUUJsOFOSVNpbo4wdQN3zV=6yndw@mail.gmail.com>
2019-01-15 14:27       ` Fredrik Strömberg
2019-01-16 16:34         ` Jose Marinez
2019-01-18  8:19           ` Fredrik Strömberg

WireGuard Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.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/ https://lore.kernel.org/wireguard \
		wireguard@lists.zx2c4.com zx2c4-wireguard@archiver.kernel.org
	public-inbox-index wireguard


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/com.zx2c4.lists.wireguard


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