From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: smajor@gmail.com Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 23b3a037 for ; Thu, 16 Nov 2017 17:40:58 +0000 (UTC) Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id cdea473f for ; Thu, 16 Nov 2017 17:40:58 +0000 (UTC) Received: by mail-wm0-f44.google.com with SMTP id 9so1818556wme.4 for ; Thu, 16 Nov 2017 09:45:21 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: From: Stephen Major Date: Thu, 16 Nov 2017 09:45:19 -0800 Message-ID: Subject: Re: Roaming Mischief To: "Jason A. Donenfeld" Content-Type: multipart/alternative; boundary="089e0822392012ab2f055e1d2f67" Cc: WireGuard mailing list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --089e0822392012ab2f055e1d2f67 Content-Type: text/plain; charset="UTF-8" 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 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@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/wireguard > --089e0822392012ab2f055e1d2f67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am by no means an expert in crypto but lets just for the= sake of paranoia say that an=C2=A0advanced attacker was able to successful= ly 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 compro= mised and basing all decisions on that. So when I think of VPN's I thin= k well if someone is listening in, whether it be an ISP or a sophisticated = encryption cracking farm installed in the Westin building in Seattle.... Ho= w do I handle this scenario? VPN Bonding, multiple tunnels 2 to a random nu= mber of tunnels bonded. a successful MITM attack only would see garbled pac= kets and the complexity in cracking a random number of tunnels and correctl= y re-assembling the packets would be seriously epic, at that point there ar= e easier ways and makes MITM pointless. So here comes the question, would B= onding also solve your=C2=A0issue?


On Tue, Nov 14, 2017 at 1:59 AM, Jaso= n A. Donenfeld <Jason@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<= br> 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 ex= ample, 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<= br> 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=3Dmy.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@lists.zx2c4.com<= br> https://lists.zx2c4.com/mailman/listinfo/wire= guard

--089e0822392012ab2f055e1d2f67--