Re: WireGuard deployment considerations for improved privacy
On Wed, Jan 16, 2019 at 5:34 PM Jose Marinez 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
Re: WireGuard deployment considerations for improved privacy
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 wrote: On Tue, Jan 15, 2019 at 1:05 PM Henning Reich 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 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: WireGuard deployment considerations for improved privacy
On Tue, Jan 15, 2019 at 1:05 PM Henning Reich 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
Re: WireGuard deployment considerations for improved privacy
On Mon, Jan 14, 2019 at 1:05 PM Henning Reich 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
Re: WireGuard deployment considerations for improved privacy
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 signature.asc Description: OpenPGP digital signature ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
WireGuard deployment considerations for improved privacy
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 ar
