I made my own WireGuard VPN server
techcrunch.com
techcrunch.com
EDIT: Updated and published, thanks again.
EDIT: I've updated the article with more information and a link to the official docs, which explain this better.
However, I found a huge error:
> Linus Torvalds himself said that he loves it, which took the software world by storm, as we weren’t aware that Linus was capable of love or any emotion other than perkele.
Linus belongs to the Swedish minority living in Finland, so while he's probably able to perkele he jävlas most of the time.
Is Wireguard similar to OpenVPN when it comes to configs?
A real-world config file can be under 10 lines for the client and under (10 + 5 * n_clients) lines for a server.
Private and public keys are short base-64 encodings of 256-bit keys and can be generated with the wg command line tool. These live inside the config file.
But what's really cool about WireGuard is how simple it is. It's far simpler than OpenVPN, and vastly simpler than IPSec/IKEv2. Given SSH logins to a pair of VPS, it takes maybe an hour at most to setup a link.
[EDIT] - when I think about it, the management with kernel internals is definitely something I couldn't do. Writing kernel-level drivers/software is not my cup of tea.
Probably.
I thought this was clever, then I realized I had just "discovered" HTTPS.
But in any case drafts for TLS over HTTP (also known as aTLS) exist: https://tools.ietf.org/html/draft-friel-tls-atls-00 https://tools.ietf.org/html/draft-friel-tls-over-http-00
You've described the obvious part - this is in any crypto intro course. But it's not even getting the details of that right (which is _a_ challenge) that's interesting, because that's not where wireguard innovates. Well it does actually propose a nice scheme, but still - OpenVPN (in TLS mode), IPSEC (with IKE, else it's DIY) and, in a way, HTTPS already have working schemes.
wireguard shines is other areas: the simple (factor 500 smaller code than IPSEC/IKE), performant and fully in-kernel (both unlike OpenVPN) implementation, ifaces instead of xfrm policies (for IPSEC. though that's not entirely far, you can have VTI's. they just don't scale well we've found.), the lessons learned wrt crypto agility (tl;dr: don't), implicit source verification, the beautiful DOS cookie implementation (feels nicer than TA key), that servers are silent/invisible unless you know their public key (cant provoke any response packets without), all connections are p2p. To name a few. Read the Wireguard paper. It's short and very approachable.
This definitely doesn't qualify as a lesson learned. It's maybe, maybe, best current practice, if you squint.
We've even seen in other threads the WireGuard author arguing that oh, well, if there's a problem with say key exchange (it has a "conventional" elliptic curve key exchange and so an adversary with a big Quantum Computer definitely breaks that) then you can still rescue with PSKs. And as well as not addressing problems in any other primitive that doesn't stand up to a laugh test. If PSKs were fine you would already use PSKs and not have all this complicated public key dance at all.
In reality if there's any problem you have to throw WireGuard itself away. So the hope is maybe all these primitives are fine. And that hope will seem 100% on the money right up until it isn't. We will see then, I think, valuable character information about its designers and key proponents, in light of how they react to that particular lesson, for example in helping people migrate off their now fatally damaged baby.
The lesson learned wasn't "don't" it was that "more is always better" is wrong, we didn't need fifteen mediocre symmetric block ciphers without much cryptanalytic research behind them in TLS. But zero agility _definitely_ hasn't proven itself to be the right choice here either, it's just less work to implement.
To be honest, when something like WireGuard becomes victim to a flaw in one of the primitives then I’d rather they release a WireGuard 2 to address it - keep as much config the same as possible but throw away any notion of backwards compatibility with vulnerable versions.
The only case where agility can be helpful is when there are different vulnerabilities known in the MAC, cipher, etc - but there is some combination you can mix-and-match that is still believably secure. I tend to side with Donenfeld here, that this improbable possibility is not worth supporting.
Note that WireGuard does have an "entire protocol" version; it's possible to support more than one at a timel; However, it does away with the 50 mix-and-match version that an agile protocol has, and the downgrade attacks that mean the whole thing is only as strong as the weakest combination.
Where? Neither a search nor a brief manual inspection of the protocol design mentions such a feature.
> it's possible to support more than one at a time
Just a moment ago you were cheering on WireGuard's simplicity and lack of vulnerability to downgrade attacks, and now we're talking about how an implementation might actually offer more than one, whereupon you're back to worrying about downgrade attacks.
TLS has a number of specific anti-downgrade countermeasures, it will not surprise anyone to discover that WireGuard's paper as well as not describing this "entire protocol" version feature you've mentioned also has nothing about downgrade prevention...
The most recent example where attackers get to do a TLS downgrade is Logjam, where they tie things up for long enough to solve the Discrete Log problem and then use their solution to cover up an earlier lie so that the downgrade protection doesn't trigger.
This sort of trick also wouldn't work against TLS 1.3's downgrade protection, because rather than use a removable sentinel they baked the sentinel into the shared entropy. This sets up a catch 22. If you remove the sentinel to hide your tracks, the connection fails due to a mismatch, but if you leave the sentinel there then a client knows what's up.
TLS is, as I said, a terrible example of how complicated handshaking can defend against downgrade attacks (for the best possible example of this, see DROWN, which actually manages to leverage SSL 2 attacks against TLS!).
On the other hand, WireGuard can't have downgrade attacks: the precise configuration of crypto constructions used in the protocol is baked into the constructions themselves as domain separation parameters.
You're very kind to Paul Kocher in naming him one of the "best in the world". Maybe he'd just gone to Vegas too when he decided you could get away with abusing RSA decryption to implicitly authenticate the recipient?
In grouping cross protocol attacks like DROWN in as downgrades you undo your own arguement. WireGuard with this unusual definition can become vulnerable to downgrade, bad guys might get your WireGuard v2 private keys by abusing the legacy WireGuard v1 protocol, the deliberate lack of compatibility between the two not withstanding.
Of course the specifics of DROWN can't work against WireGuard, nor against TLS 1.3, but you're insisting this isn't about specifics, it's a general "lesson"
Help me understand how exactly someone would get WireGuard's v1 Noise primitives, which bake the v1 construction identifiers and a v1 constant into the derivation of all secrets as the literal first step of the protocol, to generate something that would be comprehensible to a hypothetical v2 of the protocol.
No, no, you're right, back in 1996 the "best in the world" were incompetent buffoons, whereas today we know exactly how to do this right and we definitely haven't overlooked anything /s
My claim is that a cross-protocol attack like DROWN will not work on WireGuard, and I explained why.
Rather than acknowledge that explanation, you either (a) rattle off irrelevant details or (b) retreat to abstractions. But there's no abstraction to retreat to. DROWN isn't an unknowable attack. You can just read the paper to see how it works. After you do that, I suggest you read the WireGuard white paper, which is short and straightforward (the cryptographic details make up only about a third of it). You've said several things on this thread that lead me to believe you haven't yet read it, and I think you'll find it enlightening.
Pages 9 and 10 in the whitepaper, see IDENTIFIER and CONSTRUCTION.
That being said, supporting broken crypto is a bad idea. Should any of the crypto primitives be broken, the way to move forward would be to replace them, not have WireGuard support 2 protocol versions simultaneously.
> Just a moment ago you were cheering on WireGuard's simplicity and lack of vulnerability to downgrade attacks, and now we're talking about how an implementation might actually offer more than one, whereupon you're back to worrying about downgrade attacks.
Yes, but I don't think there's a conflict here - technically, you could have two versions running on two machines, and pick the "right one" through sticky UDP load-balancer session after you've seen which one replies (so long as the two versions are sufficiently different that an initiation packet for one does not qualify for the other). What I'm saying is that it can also be implemented within the same kernel, and I believe that one way or another, it will. In that sense, it's about as bad as TLS.
I believe Wireguard's opinionated design is better because it inherently pushes this up the stack; The way it is implemented now, if (and when) it needs to be replaced, it will be of comparable difficulty to switch WG1 to WG2 or WG1 to (something-else-that's-comparable)1; Unlike TLS in which the upgrade is usually "well, get the new version of this lib and you'll be ok" -- which is essentially guaranteed to be the path chosen, and since backward compatibility is often prized, is much more likely to be exploitable.
Technically speaking, the only thing one can say for sure "zero agility is simpler to implement", and "protocol agility requires a lot of care to avoid downgrade attacks, but provides backward compatibility". Everything else is basically dependent on the hard-to-estimate probabilities one assigns to "diligence of upgrades", "importance of security", "seriousness of vulnerabilities", "difficulty of configuration" which vary a lot based on your axioms.
Based on my experience, I prefer the approach WG is taking. YMMV.
No, it's not merely emergent. The handshake identifier string explicitly has a "v1" in it, and message types have explicit type identifiers.
The idea behind zero-negotiation cryptography is that if there's a problem with the primitives behind the protocol, you version the whole protocol, rather than hoping that some complicated negotiation scheme can future-proof it. No part of TLS's security problems have stemmed from "fifteen mediocre symmetric block ciphers"; rather, almost all of them have come from the TLS protocol's complicated handshaking.
But perhaps at least some of them will try to muddle along as others have described below, let's try both versions and see what works. Then we don't need a flag day... Whereupon of course they've got a downgrade problem.
Because TLS has been such an overwhelming success there have been a lot of problems.
Let's start with BEAST. BEAST attacks the way TLS 1.0 does IVs. Is that anything to do with "complicated handshaking" ? Nope, not related at all.
Soon after that there's Lucky 13. This attacks CBC modes with a timing-based padding oracle. Handshaking? Nope.
How about RC4 being broken - Handshake problem? Nope, the RC4 stream cipher is just not as good as intended.
CRIME was a compression oracle, still not handshaking.
Coppersmith's and ROCA, as well as the Debian hilarity show that even minting private keys might be too hard, at least in RSA, for people to do it correctly. Once again, not related to handshaking.
Now Logjam really does come down to the complicated handshake, although it does also need a client which is a total sucker.
Some? Yes. "Almost all" isn't correct. Lots of problems with cryptographic primitives and implementation bugs, maybe WireGuard will be popular enough to have so many implementations and to have such a large number of researchers trying to break it...
That's an interesting one to pick. It could not be fixed by negotiation and configuration at all, in the end. The entire protocol version had to be thrown away.
The die-die-die draft would never have been written if we were looking at a situation where TLS 1.0 was gone in practice on the web, let alone SMTP and other slower-moving environments. Even PCI's day-late, dollar-short June 2018 deadline would have been irrelevant if you're right. You aren't right.
No, BEAST's story is much more interesting than that, there were three mitigations and one remains widely in use.
One "configuration" mitigation was to move to RC4 since that's not a block cipher so the CBC mode attack doesn't work by definition. This is no longer considered acceptable because RC4 is way weaker than we'd thought at the time.
The next mitigation is "empty fragments". An attacker only gets to peak at certain data using BEAST (and then they expand the attack and get everything) but we can arrange for the vulnerable block to have zero length, and then the attacker didn't achieve anything for all their effort. We waste a few bytes on the wire, but this works fine by the specification. Alas, some real world implementations had been written to reject these "empty fragments", which had never been needed previously and so you couldn't actually use this in products like web browsers.
Instead client implementations began doing 1/n-1 split, which moves a single byte instead of nothing. The attacker has 1-in 2^16 chance to guess this using BEAST, but it's a single byte, so they had 1-in- 2^8 chance to guess it without BEAST, and thus BEAST is worthless if you can do this.
Of course it's still _wasteful_ but it's both protocol compliant and an effective mitigation. How about that?
Your confused argument suggests that because BEAST involved chained IVs and not the TLS handshake, it's an example of how the handshake didn't sabotage TLS. You're right: it's not. It's an example how the handshaking, which sabotaged TLS through other attacks, didn't buy anything material for TLS.
Beyond that though you seem to have your history out of order, BEAST is a TLS 1.0 attack, but TLS 1.2 was finished years before BEAST was published.
It's not a case of a protocol version "had to be burned to fix the problem" but two subsequent protocol versions had already shipped years ago which fixed the underlying cause and, as is the reality for which you seem so ill-prepared, scarcely anybody had upgraded.
All these years later financial services companies are getting waivers from PCI saying their cheap third rate POS terminal "has a mitigating control" and so it's fine that they still do TLS 1.0. So that's nice. Nice for them I mean. Hey, if you're "lucky" one day they'll be relying on a ten year out-of-date WireGuard, as enthusiastically endorsed by Thomas Ptacek. And every time you're asked about it you can spit feathers. How dare they. Like I said, if you're lucky.
As messy and uphill as it has been, the journey from SSLv2 to TLS 1.3 was only possible with the handshake.
That doesn't really address the 'agility didn't help here' point at all. The argument against agility as a design approach is straightforward and widely articulated - it's obviously informed by the SSL/TLS experience but doesn't outright depend on it. It's not too difficult to imagine that there could be some sort of coherent counter-argument. If you have one, though, it's impossible to parse it out from this enthusiastic mixture of non-responsive detail and superciliousness.
Yes, this is beautiful.
Inventive minds like yours will often have insights that aren't original, but over time and with more practice, some of these will be original and practical and valuable, and you will more often have the satisfaction of making important discoveries.
Happy to answer questions if anything's unclear.
But how does it help you stay anonymous? You are still paying for that server using your CC and they'd have your address and all other info. Unless I can rent the server anonymously, I can't see any point to run my own VPN server. That's why I'm paying a third party, PIA for example, to rent and run that server for me.
E: NVM, you mean to access your stuff without NAT etc.
Perhaps if you used Bitcoins to pay?
Some of Britain's smaller IPSs don't like this sort of stuff (e.g. Andrews and Arnold's "implementation" of the government's opt-in child friendly censorship was to have a checkbox on their application page, if you say you want censorship it says you should choose a different ISP...), and so the smart money is on them having not written to ISPs at all. The backbone providers are few, bigger, and much more corporate. No colourful personalities apt to make the government look a fool in a televised hearing. So any letters probably went to the backbone providers although so far as I know none have come forward to say so.
In 2017 the ECJ told the UK government that such mass surveillance is prohibited, and it is also widely rumoured that the government then told the backbone providers to pause the collection.
Doing that kind of analysis has become very easy and cheap recently.
I'd wager that quite a few people would like to pay for a managed VPN service that did the same thing.... however, as once in a while you need to disable your adblocker on some websites, so once in a while you might need to circumvent the blocking on the VPN. I wonder how that might be done.
OpenVPN on Android lets you select apps to bypass the VPN, so I have a second browser on standby if I ever need direct internet access. Or I could use the disable for x minutes feature of pi-hole.
Proper ipv6, shared ipv4 with a port range forwarded for you to use.
Besides that, though, the entire mechanism of Bitcoin is one where all transactions are recorded publicly in perpetuity. It's really the polar opposite of private in that respect. It means that if your identity is ever linked to a particular bitcoin address (as in the not-so-unlikely scenario that the authorities or some other attacker are monitoring bitcoin-for-cash machines), then all transactions linked to that address can be linked to you.
In short, as always, it depends on your threat model. Are you trying to hide the fact that you forwarded sensitive nuclear secrets to overseas actors from a determined U.S. Government investigation? Sorry, you probably can't, at least without a bit of luck. Are you trying to fool Netflix long enough to stream latest season of Arrested Development? Probably doable.
Masking your face is also cheap and easy to do if you are really concerned about it.
I don't see the purpose of VPNs as anonymity, and I think many people are making a mistake to see them that way. If anyone really wanted to know who you are, they could file a suit and subpoena PIA. Now you're trusting that PIA really doesn't keep any logs. You have no way of verifying this. Or, if someone has some suspicions about who (and where) you are, they could subpoena their billing information. If someone (particularly a government) really wants to find you, a VPN does little to stop them. You've just introduced a single middleman.
On top of that, you can only take PIA's assurances that they themselves are not tracking you.
I run my own VPN server, hosted in a DO droplet, to get around networks that filter certain ports and websites. That's it. I have considered adding a VM with read-only access to my NAS to the VPN but that's all.
"block-outside-dns"
then run this test:
I pass the extended test with it. Very easy and worth doing.
PrivateKey = !peername
Publickey = !peername
And the actual credentials could be in a separate file with a specific name, with one peer per line:
peername:pubkeystring:privkeystring
That would make deployments much easier, as the credentials could be handled separately.
However, the peer address assignment is another good question. One file per peer would be better, I think, but you'd need something like another directory, and, at that point, you might as well write a script to take all your config and concatenate it into one file. That having been said, I don't know why that can't be a part of wg-quick.
Using a TCP based VPN there are services such as ngrok for exposing only the VPN endpoint behind a NAT, but nothing equivalent for UDP.
Unless it's possible to use the android and other clients to work in this way, it will limit the uptake of this, I believe.
For clients, it works like all other UDP applications, it just reaches out to the remote address and the NAT keeps a temporary mapping of the source and destination ports and addresses.
Has anyone made any experience with TunSafe?
[1] https://lists.zx2c4.com/pipermail/wireguard/2018-March/00244...
I got the impression that ludde (the author of TunSafe) seems to think that people should trust him because he wrote uTorrent and he is, for reasons not specified, opposed to releasing it open source and suggests that the author of wireguard has a "general dislike against non open-source applications."
For what it's worth I really cannot understand the mentality that would lead to you creating a high-quality, benign VPN client that you have no intention to charge for or sell and not wanting eyes (which have certainly been offered) to look over it before users rely on it.
There's nothing wrong with non open-source applications in general, but when it's a closed-source client of an open-source VPN server, you can't trust it, sorry.
Not necessarily. Depends on what license you use for the code, but if it's not a copyleft license they can't even create a (legal) copy if you maintain copyright and don't give anyone a license to copy the code.
I find OpenVPN plenty fast for personal use (with adjusted send/receive buffers and AES-NI on the server)
I believe you can use wireguard-go on android, which doesn't require a kernel module.
[0] https://play.google.com/store/apps/details?id=com.wireguard....
Advertorial?
Sustained use discount and top notch network further the case.