Hacker News new | ask | show | jobs
by zx2c4 2560 days ago
Work is progressing steadily by the day on WireGuard for Windows and Wintun, the TUN driver we're writing that this uses. Hopefully this won't be "pre-alpha" for much longer.

You can get the former at https://www.wireguard.com/install/ and learn about the latter at https://www.wintun.net/

3 comments

In the previous discussion thread linked below, somebody claims WireGuard is subject to DPI. An examination of the White Paper and of real packet captures does not reveal any obvious opportunity to "inspect" WireGuard if you aren't in possession of the keys.

Most likely that poster uses DPI sloppily to include simple blocking strategies, like hey, if we see two packets in a row between two (ip,port) pairs starting 01 00 00 00 going on way and then 02 00 00 00 going the other way, that could be WireGuard, let's block the rest of the data on that (ip,port) pair for a while.

However, am I missing something and actually there is something meaningful to inspect without having the keys?

If I'm not, what's your preferred way for people to sidestep that sort of blocking? Tweaking WireGuard to use different values would obviously work but it destroys the point of having a single specification.

DPI doesn’t imply any ability to decrypt the traffic. It refers to networking equipment fingerprinting the traffic to detect application/protocol information (basically anything in the OSI model lower than layer3/4)

That aligns with the DPI-related comments in the linked prior comment thread, which reference use of DPI for internet firewalling by various governments.

Also, as noted in that same comment thread, bypassing DPI is an un-goal of Wireguard.

> It refers to networking equipment fingerprinting the traffic to detect application/protocol information (basically anything in the OSI model lower than layer3/4)

Right, so then is your claim that there _is_ such information revealed in WireGuard? Because I don't see any.

If you do DPI for - say - TLS you get a strong fingerprint (JA3 is a popular thing for this) that lets you distinguish Google from Twitter, Firefox from Safari, or curl from Python's Requests, again without decrypting the traffic.

But where is the fingerprint in WireGuard? If I give you a tcpdump for 5 minutes of UDP traffic the most you can say is that some of it looks like WireGuard traffic. You might remember when we used to get this sort of useless diagnostic, "Over 4000 of these packets use port 80! This is web traffic". We did not call that "Deep Packet Inspection" because it wasn't deep and didn't in fact inspect the packets, just some metadata.

https://lists.zx2c4.com/pipermail/wireguard/2018-September/0...

From the Wireguard mailing list, there is an application layer fingerprint that is easy to detect.

I’m not sure what case you’re trying to make. Yes, network equipment can do pattern-matching on Wireguard traffic and have reasonable confidence based on the packet contents and flow patterns that the traffic is a Wireguard VPN.

For example: https://ipoque.com/news-media/press-releases/2019/rohde-schw...

Edit: also, to clarify the note you had about port 80, that’s why I pointed out that DPI refers to layers beyond 3/4. “Hey these are TCP packets to port 80” is not DPI. “Hey, the contents of these packets match my signature for Wireguard traffic” is DPI.

> "Over 4000 of these packets use port 80! This is web traffic". We did not call that "Deep Packet Inspection"

The right analogy is "these packets went through these tubes".

What would it take to have a TUN-less client that exposes the VPN connection as a SOCKS proxy? The use case I'm imagining is being able to sit down at a machine as an unprivileged user, connect to a VPN, then run Firefox Portable and have all traffic from the browser go through the VPN, all without having to install anything.
I'm afraid it's not super clear here. Are you working on a Windows SERVER/DAEMON for WireGuard as well as a client, or just a client?
With wireguard there is no difference - there are no servers and clients, just peers.
Very interesting. Thank you!