In other comments the author seems to already be aware, but for anyone wondering why TCP over TCP is less than ideal, this is a good read: http://sites.inka.de/bigred/devel/tcp-tcp.html
Show HN: Encrypted VPN in 2k lines of Go
51–60 of 66 posts
Re: Show HN: Encrypted VPN in 2k lines of Go
#52Earlier quoted context omitted.
Because you can easily read and understand the code.
For what it’s worth, this only really applies to a comparison against OpenVPN or IPSec. WireGuard has similar code complexity and size, and is approximately the same when compared against the incumbent VPN options.
I don't think the comparison to Wireguard is apples-to-apples. Wireguard implements it's own semi-custom cryptosystem (Noise) whereas subnet rides on top of Go standard TLS implementation. So depending on how you view things, Wireguard is either much simpler (if you compare to the whole TLS stack) or much more complex (if you assume Go TLS to be reliable/trustworthy)
Re: Show HN: Encrypted VPN in 2k lines of Go
#53Related: Wireguard is a new VPN for linux in 4k lines of C https://www.wireguard.com/ the model of wireguard has been proven correct by formal methods. Builds on modern crypto, and they kept code short for auditing purposes.
My concern is that 'built on modern crypto' and 'reviewed by cryptographers' amounts to 'rolled our own crypto'. IMHO history has shown us time and time again that this is a bad idea - we should use the protocols and ciphers that have stood the test of time. Building subnet using TLS was an architectural choice to avoid playing the role of cryptographer and inevitably getting it wrong.
It builds on Noise, which is very highly regarded and reasonably well researched in crypto circles. Ironically (vis-a-vis your comment), it was designed largely to avoid the mistakes inherent in developers "rolling [their] own" crypto on TLS with poorly chosen stacks, ciphers, parameters, downgrade criteria, etc.
Re: Show HN: Encrypted VPN in 2k lines of Go
#54sshuttle is another great tool with a similar use case. One advantage is that it doesn't require any server setup at all, as long as you have ssh access. https://github.com/sshuttle/sshuttle
A neat thing about sshuttle is that it restreams TCP connections inside of the SSH tunnel so that you don't incur the classic TCP-over-TCP problem [1].
[1] http://sshuttle.readthedocs.io/en/stable/how-it-works.html
Re: Show HN: Encrypted VPN in 2k lines of Go
#55Earlier quoted context omitted.
Because you can easily read and understand the code.
For what it’s worth, this only really applies to a comparison against OpenVPN or IPSec. WireGuard has similar code complexity and size, and is approximately the same when compared against the incumbent VPN options.
Maybe I misunderstood your comment, but WireGuard is less than 4k LoC, which is a few orders of magnitude smaller than OpenVPN or IPsec.
Re: Show HN: Encrypted VPN in 2k lines of Go
#56Earlier quoted context omitted.
For what it’s worth, this only really applies to a comparison against OpenVPN or IPSec. WireGuard has similar code complexity and size, and is approximately the same when compared against the incumbent VPN options.
Maybe I misunderstood your comment, but WireGuard is less than 4k LoC, which is a few orders of magnitude smaller than OpenVPN or IPsec.
Yep you misunderstood, I was saying WireGuard has similar code complexity to the Go VPN implementation linked here :)
Re: Show HN: Encrypted VPN in 2k lines of Go
#57Earlier quoted context omitted.
From the linked page: > There is no group of users that should be using the code in this repository here under any circumstances at the moment, not even beta testers or dare devils. Despite the warning I attempted to use it, but without any real docs I didn't get very far.
The Go implementation is not done yet! But it will be soon. In the meantime, feel free to use the Linux kernel implementation, which works quite well and has extensive documentation and man pages: - https://www.wireguard.com/ - https://www.wireguard.com/quickstart/ - https://www.wireguard.com/install/ - https://git.zx2c4.com/WireGuard/about/src/tools/wg.8 - https://git.zx2c4.com/WireGuard/about/src/tools/wg-quick.8
I’ve played with the Linux implementation, I love it!
But I use a Mac so I can’t join the VPN I made :/
Re: Show HN: Encrypted VPN in 2k lines of Go
#58Earlier quoted context omitted.
The Go implementation is not done yet! But it will be soon. In the meantime, feel free to use the Linux kernel implementation, which works quite well and has extensive documentation and man pages: - https://www.wireguard.com/ - https://www.wireguard.com/quickstart/ - https://www.wireguard.com/install/ - https://git.zx2c4.com/WireGuard/about/src/tools/wg.8 - https://git.zx2c4.com/WireGuard/about/src/tools/wg-quick.8
I’ve played with the Linux implementation, I love it! But I use a Mac so I can’t join the VPN I made :/
If you join the mailing list [1], there'll be an announcement when it's ready, which hopefully won't be before long. Other perks include free stickers too :D [2].
[1] Send a blank email to wireguard-join at lists dot zx2c4 dot com.
[2] https://lists.zx2c4.com/pipermail/wireguard/2017-May/001338....
Re: Show HN: Encrypted VPN in 2k lines of Go
#59Earlier quoted context omitted.
My concern is that 'built on modern crypto' and 'reviewed by cryptographers' amounts to 'rolled our own crypto'. IMHO history has shown us time and time again that this is a bad idea - we should use the protocols and ciphers that have stood the test of time. Building subnet using TLS was an architectural choice to avoid playing the role of cryptographer and inevitably getting it wrong.
What a bunch of senseless FUD. WireGuard is based on the Noise Protocol Framework [1], designed by the same fella as the Signal Protocol, and already used in production by millions of devices all around the world inside of WhatsApp. Not only that, but we have a formal verification [2] that the crypto is correct in the symbolic model. The WireGuard paper itself [3] was presented to the academic community at NDSS [4].…
> What a bunch of senseless FUD.
inb4 strawman arguments and other funzies.
Perhaps you should argue with me on my actual assertion, which is that 'we should use crypto that has stood the test and scrutiny of time'. Do not interpret my criticism as a personal attack.
> already used in production by millions of devices all around the world inside of WhatsApp.
Cool. This is good because that means we have a lot of eyes looking at it.
> formal verification that the crypto is correct in the symbolic model.
This is great and we need more of this kind of work. I don't think its good enough however; most practical attacks rely on side channels, implementation mistakes (formal verification helps in catching these but don't get you all the way), and other obscurities. I stand by my assertion that we should use crypto that has stood the test of time.
> The WireGuard paper itself [3] was presented to the academic community at NDSS
Congrats I guess? relevance?
> not the hastily-made nonsense you imply it is with the phrase "rolled our own crypto"
I made no such implication. 'Roll your own crypto' is a common phrase (at least in my circles) meaning to do it yourself instead of depend on someone else's implementation. Again, I don't see what this has to do with my assertion to use old and battle tested crypto.
> "subnet", tunnels TCP over TCP, which is well known for having pathologically bad performance characteristics
Correct, have a gold star. What does this have to do with crypto?
As you could tell if you scrolled down and read the other discussions around TCP-in-TCP, I am fully aware of the implication of my design decision, and stand by it is the right balance of simplicity, security, and speed (well, thats relative, but for what I was intending it for).
> It also has no binding between certificates and the IP addresses that a certificate is allowed to be inside the tunnel, and, unless I've misread, it allows different peers to hijack each others' IP addresses simply by asking
Correct, I am making the assumption that if posess a private key and cert minted by the server you are trusted. This could be fixed at the cost of additional complexity, loosing the ability for a client to change his address, and less alcohol-time on the developers part. That said, if someone asked me to network together hostile entities, I would have given him some coolaid instead of Go code. But I'm digressing, lets get back on topic.
> But please don't spread FUD about other projects without first understanding them.
I have done no such thing. I stand by my assertion that we should use Crypto that has stood the test of time. Am I not allowed to raise such assertions and discuss them on merit?
Re: Show HN: Encrypted VPN in 2k lines of Go
#60Earlier quoted context omitted.
My concern is that 'built on modern crypto' and 'reviewed by cryptographers' amounts to 'rolled our own crypto'. IMHO history has shown us time and time again that this is a bad idea - we should use the protocols and ciphers that have stood the test of time. Building subnet using TLS was an architectural choice to avoid playing the role of cryptographer and inevitably getting it wrong.
It builds on Noise, which is very highly regarded and reasonably well researched in crypto circles. Ironically (vis-a-vis your comment), it was designed largely to avoid the mistakes inherent in developers "rolling [their] own" crypto on TLS with poorly chosen stacks, ciphers, parameters, downgrade criteria, etc. https://noiseprotocol.org/noise.html
Guess you could say noise is pretty quiet xD
+1 for trying to eliminate complexity from developer error. This was one of the worst cows in the herd for OpenSSL.
That said, I think a bit of good design on the APIs part can go a long way. For Instance, I think Go's crypto/tls aint bad: Its pretty difficult to 'accidentally' configure it in a shocking configuration (suites have to be overridden, turning off verification requires you to set a field called InsecureNoVerify etc).