OK, that's cool and all.
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.
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.
Happy to answer questions if anything's unclear.
[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.
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.
Yes, this is beautiful.
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.
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.
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.
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.
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