This project has so many cryptographic wrong answers, I don't know where to begin.
Glaring problems:
- The same unchanging aes key is shared between all nodes on a network. Compromise one, compromise all. Additionally a bad node can impersonate any other node.
- The 96 bit nonce is derived randomly and there is no rekeying which means sending more than 2^32 messages will leak your (static, unchanging) key to the world. That's 2^32 total between all clients on a network. Hope everyone is manually updating their keys!
- Default unchanging password of `hello-world` is set. Everyone remembers to change that environment variable right?
- The KDF is md5, which means attackers can brute force guess the key incredibly fast.
- There's no perfect forward secrecy (aging out of old keys).
Amazingly, this is still better than their last version, which used AES-CBC and used the same value for both the key and the IV (which is transmitted over the network).
Kind of. What I meant is "it won't work for all double NAT setups". In practice, if you have upnp on both sides or a setup which allows holepunching for any source it will work. (usually) But after working for a VoIP provider, I don't trust those anymore. Your home router will have some edge cases, or the mapping detection will fail, or something else will happen. If you're trying to connect 2 parties reliably, they need a proxy or direct access on one side.
1) They switched away from UDP, now use TCP. So NAT traversal / punching isn’t possible.
2) Even if UDP was used there’s still some network setups that aren’t traversal friendly, such as most cellular/LTE networks where port mappings are unpredictable.
TCP-based NAT punching is perfectly possible. Not that it’s needed often in systems that employ punching (due to it being a fallback option if UDP is unavailable), but it’s easy to do and works well.
How does that work? NATs (usually?) track TCP state. That means party A sends a SYN and will only pass in SYN-ACK. Party B's NAT drops SYN on the floor. Same happens the other direction. It works for UDP because there's no concept of an established connection, but TCP?
Clients A and B connect to a rendezvous host. R looks at A and B's ports, guesses which ports they will use for the next connection and instructs them to connect to each other respectively. First SYN packets are lost, but they poke holes, so on the retry the symmetrical open kicks in and peers hook up into a shared TCP connection. The end.
Again, that's only if the NAT allows this. Not all of them do and not all of them will have predictable port mappings. See http://www.ijimt.org/papers/226-G0027.pdf for example for details about what works when.
It's been a while since I worked on this, but back then over 80% NAT devices used simple +1 port allocation. Some fraction was using other increments and only OpenBSD used truly random overloading. The main issue with port prediction in general wasn't making it per se, but making it quick enough so that it won't expire.
From what I remember ingress TCP filtering was universally very dumb - if there was a SYN out, anything on the same quartet of IP/ports was allowed in. That was on a sample of several thousand devices, though most of these were of consumer grade. It was also few years before the paper you linked to above.
The quality seems a bit low. There is a similar project based on academic routing protocol Babel and implemented reliably by a professional called Re6st https://re6st.nexedi.com
Re6st indeed is more focused on connectivity than performance because it re-establish connection even when the Chinese great firewall kicks in.
In the previous discussion HN users were complaining about
"AES-256 in CBC mode but without an authentication tag (HMAC)". Is this still the case or has it been addressed?
Also, any idea the overhead in terms of CPU pushing around 100Mbps?
There are scant details on the website as to _how_ it works. They don't appear to backup the claim that its "distributed"
Are they just using a DHT to distribute IP addresses, then use wireguard to connect? how is routing configured? is it dynamic.
All of the basics seem to require looking into the code, which seems a little obtuse
also, wget'ing a script direct into sh, not a healthy start. easy installers == great, but not when its piped directly into sh. Tar.gz and make it obvious that your not hiding stuff, and make sure you post a hash of the tar.
Glaring problems: - The same unchanging aes key is shared between all nodes on a network. Compromise one, compromise all. Additionally a bad node can impersonate any other node.
Amazingly, this is still better than their last version, which used AES-CBC and used the same value for both the key and the IV (which is transmitted over the network).Summary: Stick to Wireguard!