Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Thursday December 12 2019, @06:12AM   Printer-friendly
from the protected-communications dept.

WireGuard VPN is a step closer to mainstream adoption

As of this morning, Linux network stack maintainer David Miller has committed the WireGuard VPN project into the Linux "net-next" source tree. Miller maintains both net and net-next—the source trees governing the current implementation of the Linux kernel networking stack and the implementation of the next Linux kernel's networking stack, respectively.

This is a major step forward for the WireGuard VPN project. Net-next gets pulled into the new Linux kernel during its two-week merge window, where it becomes net. With WireGuard already a part of net-next, this means that—barring unexpected issues—there should be a Linux kernel 5.6 release candidate with built-in WireGuard in early 2020. Mainline kernel inclusion of WireGuard should lead to significantly higher uptake in projects and organizations requiring virtual private network capability.

[Ed. addition] Wireguard implements a fast, modern, secure VPN tunnel. According to Wikipedia:

WireGuard is a free and open-source software application and communication protocol that implements virtual private network (VPN) techniques to create secure point-to-point connections in routed or bridged configurations. It is run as a module inside the Linux kernel and aims for better performance than the IPsec and OpenVPN tunneling protocols. It was written by Jason A. Donenfeld and is published under the second version of the GNU General Public License (GPL).


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Interesting) by The Shire on Thursday December 12 2019, @04:32PM (4 children)

    by The Shire (5824) on Thursday December 12 2019, @04:32PM (#931446)

    This is a dream for anyone interested in surveillance. WireGuard has a number of severe privacy flaws baked into it.

    1) Wireguard lacks dynamic IP address management. The client needs to be assigned in advance a pre-defined VPN IP address uniquely linked to its key on each VPN server.

    2) The Wireguard client does not verify the server identity.

    3) TCP support is missing!

    4) There is no support to connect Wireguard to a VPN server over a proxy with additional authentication methods.

    5) No single user should be statically allocated a single IP address, neither on a public nor a virtual network. A user’s internal IP address might be discovered by an adversary (through WebRTC, for example), who might then be able to match it with records acquired from a VPN provider (through theft, sale, or legal seizure).

    Basically, by design, WireGuard completely exposes the client at the endpoint even if the connection between the client and the VPN server is secure. This means anyone operating a WireGuard VPN commercially can monitor your traffic and should that commercial provider ever be comprimised, either by legal warrant or by theft, everything you do has been recorded.

    This will work well for corporate links, but for a journalist or activist working in communist China it's completely useless.

    Starting Score:    1  point
    Moderation   +3  
       Interesting=2, Informative=1, Total=3
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 2) by maxwell demon on Thursday December 12 2019, @07:31PM (3 children)

    by maxwell demon (1608) on Thursday December 12 2019, @07:31PM (#931502) Journal

    What's wrong with different VPN technologies optimized for different use scenarios? I don't think OpenVPN will magically go away juts because WireGuard is in the kernel.

    Indeed, connecting to my employer's network has been my main use of VPN up to now. I'm pretty sure an employer has a legitimate interest to know who connects to the internal network.

    --
    The Tao of math: The numbers you can count are not the real numbers.
    • (Score: 2) by The Shire on Thursday December 12 2019, @07:44PM (2 children)

      by The Shire (5824) on Thursday December 12 2019, @07:44PM (#931509)

      Absolutely nothing wrong with different VPN tech, so long as the end user understands the level of privacy being offered. Existing privacy based VPN providers do so in a "logless" way meaning that if they are comprimised one way or another, the user info isn't there to be exploited. My point is only that WireGuard is inherently incapable of providing that level of endpoint privacy.

      As I mentioned, in a corporate environment this looks to be very useful. But if you're somehwere like Iran or China, WireGuard is no different than having no VPN at all. It's not safe.

      • (Score: 2, Informative) by Anonymous Coward on Thursday December 12 2019, @10:03PM (1 child)

        by Anonymous Coward on Thursday December 12 2019, @10:03PM (#931549)
        I think your concerns are slightly exaggerated and creating FUD around this new protocol.

        1) No dynamic IP address management: True for the base implementation, BUT there are efforts to address this. One of the first Google hits shows the WireGuard team have work in progress with wg_dynamic [github.com]. This is interesting in that it levarages link-local IPv6 addresses to effectively bootstrap the link so that an IPv4 address can be exchanged and assigned over the link once the tunnel is up. Yes it's work in progress, but so is the base software. But even with dynamic IP assignments, something needs to keep track of the assignments, even for other VPN protocols.

        2) No server identity verification: Not quite true, the client needs to know the server's public key. If the matching private key on the server is compromised, or the server itself compromised, then this is no different impact to privacy than if a traditional protocol VPN server were equally compromised such as server hacked or certificate private key leak. I would even argue this public-key based trust system is potentially stronger than a certificate based one where the certificates might chain up to an untrusted (or less trusted) issuer. Certificates have more moving parts to break, yadda yadda.

        3) TCP support missing: Well it's missing in IPSEC VPNs as well. There's always OpenVPN or SSL VPNs as fallback if you need to establish a VPN over TCP for whatever reason. But if you do, be wary of throughput being killed if both the inner TCP session and VPN's TCP session wrapping the tunnel both need to do TCP backoff at the same time. There's a reason UDP for VPN tunnels is preferred, especially when it comes to throughput and performance.

        4) No support to tunnel through authenticated proxies: Again, IPSEC doesn't have this either. I'm not aware OpenVPN can do this either, but I might be wrong, given that OpenVPN supports TCP, so shouldn't be too difficult to add support to issue a TCP CONNECT request via a proxy with some sort of credentials. A wrapper tool could be used to do this too.

        5) More static IP gripes: See point 1.

        As for worrying about the commercial operator monitoring the traffic or if that server is compromised at that end of the tunnel? Same applies to existing VPN technology. It's not an issue unique to WireGuard. Even where you point out "logless" operations, "logless" only applies to if the server is physically stolen and power removed - all operation data is lost in that case. But if the server is compromised and continues running, then even current VPN technologies are susceptable to monitoring once root access has been gained - at the very least existing sessions will be retrievable, since the server needs to know where and how to send the traffic for those connections. Again, not an issue unique to WireGuard.


        Now I'm not saying WireGuard is perfect, it's still work in progress after all. I personally wouldn't use it yet outside testing, but I'm interested to see where it goes because it has it's benefits.

        I think WireGuard is a better fit for replacing site-to-site type VPNs, centrally managed infrastructures or other infrastructure where all the servers and clients are under the same administrative domain such as in corporate use, or where automation is used heavily for provisioning such as Docker. One of the use cases mentioned on the website is for securing Docker container traffic on the wire, by forcing it to always communicate encrypted to anything outside itself, without any config within the container itself - the host is doing all the tunneling and encryption.

        For client-server type VPNs, especially for public VPN providers, then yes, perhaps it's a bit lacking, especially around points 3 and 4. But neither of those are privacy issues, they're more for trying to establish a tunnel through networks with built-in restrictions in them. For that, I'd say stick to OpenVPN-type technologies for now. As you say though, as long as the VPN provider makes it clear the differences between the different types of technology they offer so the user has an informed choice, I don't see an issue with offering this new protocol.
        • (Score: 2) by The Shire on Friday December 13 2019, @12:47AM

          by The Shire (5824) on Friday December 13 2019, @12:47AM (#931583)

          My bullet points are actually quotes from existing VPN providers: AzireVPN, VPN.ac, TorGuard, Mullvad, IVPN, NordVPN, and Private Internet Access. I imagine they know what they're talking about.

          And while I have repeatedly agreed that WireGuard will likely be an excellent corporate VPN, I think it's safe to say it's not yet to be trusted for trying to do anything anonymously on the net.

          When it comes to security, never be the first guy to try it!