Roaming Mischief

[Stephen Major]

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?


On Tue, Nov 14, 2017 at 1:59 AM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:

> Hey folks,
>
> WireGuard has been built with the general rule that unauthenticated
> data doesn't influence state. There has always been one exception to
> this: roaming. The source IP address when roaming is always
> unauthenticated, and replies always happen to the source that prompted
> the reply. This means there is all sorts of mischief you can do. I
> thought it might be useful to write down a bit of this mischief.
>
> If an active man in the middle modifies a source address, he can have
> reply packets sent elsewhere, for a very limited amount of time, until
> either the encapsulated connection is dropped or the key expires and a
> handshake is needed. This kind of disruption, however, isn't that much
> different from what an active man in the middle already can do, by
> just dropping packets, or generating packets, etc.
>
> If an active man in the middle modifies a source address to be a
> server he controls, which then relays encrypted packets between the
> destination and the original source, then the sender and receiver will
> communicate through this server rather than directly. The
> communication is, of course, encrypted and authenticated, so there's
> no chance of tampering. It's mostly then just a waste of bandwidth
> resources of the attacker, to have to relay all of these unreadable
> and unmodifiable packets. However, this does make it possible to
> _extend the duration_ of a man in the middle attack, even if the man
> in the middle can't do anything with the packets. For example, an
> attacker at a coffee shop could change the endpoints to his relay
> server; when you go home, you'd ostensibly still be using that relay
> server.
>
> Is this a meaningful attack? Does anybody care? Can this be used for
> something interesting? When it comes to security of these things,
> "probably" is usually a better answer than "no". For example, even
> though the attacker with the MITM relay can't read or modify any
> packets, he may still be able to do timing correlation attacks, if he
> controls many points on the Internet. But was WireGuard ever supposed
> to protect against correlation issues? Correlation issues already
> exist without the relay anyway. And for what it's worth, Tor doesn't
> really deal with that either. So maybe this doesn't really matter. But
> perhaps there are worse things one can do with this primitive. And
> perhaps there's even further mischief.
>
> There is a mitigating factor in this that further makes it mostly not
> a practical concern: people who are looking up their endpoints using
> DNS are likely to want requery that DNS entry based on its TTL (or
> sooner in the case of dynamic IPs), in which case this aspect of
> extending the duration of an active MITM mostly goes away. However,
> telling people to use DNS to prevent against something something
> doesn't really seem like comprehensive advice. But it is a mitigating
> factor worth mentioning.
>
> So there are two attitudes toward this mischief. The first is to just
> say it doesn't matter. WireGuard's crypto is resilient to all types of
> men in the middle, and the fact of extending the duration of a man in
> the middle doesn't change the fact that WireGuard's crypto is still
> resilient. The other approach would be to add an optional exclamation
> mark to the end of an endpoint specification
> (Endpoint=my.server.whatever.zx2c4.com:51820!), that would prevent
> servers from roaming; the client would still roam in the eyes of the
> server, but the server, would no longer roam in the eyes of the
> client. In other words, an option -- gasp, a nob! -- to disable
> roaming on a per-by-peer one-sided basis. As you know, I don't really
> like nobs. And I'd hate to add this, and then for people to use it,
> and then loose some nice aspects of roaming, if it's not really even
> required.
>
> Regardless of which attitude we pick, I thought it might be a decent
> idea to write this down on the list. This is not really new -- roaming
> has been discussed in the literature for a long time now -- but it is
> interesting. And of course I'm interested to hear your thoughts.
>
> Jason
> _______________________________________________
> WireGuard mailing list
> WireGuard at lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20171116/b2fc5ccc/attachment.html>