<div dir="ltr">I am by no means an expert in crypto but lets just for the sake of paranoia say that an advanced attacker was able to successfully pull off a MITM like is possible with TLS and rumored OpenVPN.Personally, my approach to security is having the mindset of everything can be compromised and basing all decisions on that. So when I think of VPN's I think well if someone is listening in, whether it be an ISP or a sophisticated encryption cracking farm installed in the Westin building in Seattle.... How do I handle this scenario? VPN Bonding, multiple tunnels 2 to a random number of tunnels bonded. a successful MITM attack only would see garbled packets and the complexity in cracking a random number of tunnels and correctly re-assembling the packets would be seriously epic, at that point there are easier ways and makes MITM pointless. So here comes the question, would Bonding also solve your issue?<div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 14, 2017 at 1:59 AM, Jason A. Donenfeld <span dir="ltr"><<a href="mailto:Jason@zx2c4.com" target="_blank">Jason@zx2c4.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey folks,<br>
<br>
WireGuard has been built with the general rule that unauthenticated<br>
data doesn't influence state. There has always been one exception to<br>
this: roaming. The source IP address when roaming is always<br>
unauthenticated, and replies always happen to the source that prompted<br>
the reply. This means there is all sorts of mischief you can do. I<br>
thought it might be useful to write down a bit of this mischief.<br>
<br>
If an active man in the middle modifies a source address, he can have<br>
reply packets sent elsewhere, for a very limited amount of time, until<br>
either the encapsulated connection is dropped or the key expires and a<br>
handshake is needed. This kind of disruption, however, isn't that much<br>
different from what an active man in the middle already can do, by<br>
just dropping packets, or generating packets, etc.<br>
<br>
If an active man in the middle modifies a source address to be a<br>
server he controls, which then relays encrypted packets between the<br>
destination and the original source, then the sender and receiver will<br>
communicate through this server rather than directly. The<br>
communication is, of course, encrypted and authenticated, so there's<br>
no chance of tampering. It's mostly then just a waste of bandwidth<br>
resources of the attacker, to have to relay all of these unreadable<br>
and unmodifiable packets. However, this does make it possible to<br>
_extend the duration_ of a man in the middle attack, even if the man<br>
in the middle can't do anything with the packets. For example, an<br>
attacker at a coffee shop could change the endpoints to his relay<br>
server; when you go home, you'd ostensibly still be using that relay<br>
server.<br>
<br>
Is this a meaningful attack? Does anybody care? Can this be used for<br>
something interesting? When it comes to security of these things,<br>
"probably" is usually a better answer than "no". For example, even<br>
though the attacker with the MITM relay can't read or modify any<br>
packets, he may still be able to do timing correlation attacks, if he<br>
controls many points on the Internet. But was WireGuard ever supposed<br>
to protect against correlation issues? Correlation issues already<br>
exist without the relay anyway. And for what it's worth, Tor doesn't<br>
really deal with that either. So maybe this doesn't really matter. But<br>
perhaps there are worse things one can do with this primitive. And<br>
perhaps there's even further mischief.<br>
<br>
There is a mitigating factor in this that further makes it mostly not<br>
a practical concern: people who are looking up their endpoints using<br>
DNS are likely to want requery that DNS entry based on its TTL (or<br>
sooner in the case of dynamic IPs), in which case this aspect of<br>
extending the duration of an active MITM mostly goes away. However,<br>
telling people to use DNS to prevent against something something<br>
doesn't really seem like comprehensive advice. But it is a mitigating<br>
factor worth mentioning.<br>
<br>
So there are two attitudes toward this mischief. The first is to just<br>
say it doesn't matter. WireGuard's crypto is resilient to all types of<br>
men in the middle, and the fact of extending the duration of a man in<br>
the middle doesn't change the fact that WireGuard's crypto is still<br>
resilient. The other approach would be to add an optional exclamation<br>
mark to the end of an endpoint specification<br>
(Endpoint=my.server.whatever.<wbr>zx2c4.com:51820!), that would prevent<br>
servers from roaming; the client would still roam in the eyes of the<br>
server, but the server, would no longer roam in the eyes of the<br>
client. In other words, an option -- gasp, a nob! -- to disable<br>
roaming on a per-by-peer one-sided basis. As you know, I don't really<br>
like nobs. And I'd hate to add this, and then for people to use it,<br>
and then loose some nice aspects of roaming, if it's not really even<br>
required.<br>
<br>
Regardless of which attitude we pick, I thought it might be a decent<br>
idea to write this down on the list. This is not really new -- roaming<br>
has been discussed in the literature for a long time now -- but it is<br>
interesting. And of course I'm interested to hear your thoughts.<br>
<br>
Jason<br>
______________________________<wbr>_________________<br>
WireGuard mailing list<br>
<a href="mailto:WireGuard@lists.zx2c4.com">WireGuard@lists.zx2c4.com</a><br>
<a href="https://lists.zx2c4.com/mailman/listinfo/wireguard" rel="noreferrer" target="_blank">https://lists.zx2c4.com/<wbr>mailman/listinfo/wireguard</a><br>
</blockquote></div><br></div>