From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: chm.duquesne@gmail.com Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id f38e3716 for ; Mon, 7 May 2018 13:33:38 +0000 (UTC) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id fa54396d for ; Mon, 7 May 2018 13:33:38 +0000 (UTC) Received: by mail-io0-x233.google.com with SMTP id d73-v6so33649558iog.3 for ; Mon, 07 May 2018 06:36:00 -0700 (PDT) MIME-Version: 1.0 Sender: chm.duquesne@gmail.com In-Reply-To: References: <73430f93-d7fa-777b-df24-ef4cb0021f0b@gmx.net> <493b3bdf-3cf0-5594-dd7e-4b9c8d84e74c@gmx.net> <4ZK0EJ5btb88Qoa6vz0bpYJHCbhF7h4Z-BBh0ARD4tdwxcwcmdGeUPFuiPrGcdTNmp8Q8p6t4c4vMo7vKwnEIrXdVe56ovqOhiBXi4PdPxs=@protonmail.ch> <825a636f-9311-688d-6f30-9ae8d12ea44a@gmx.net> <874ljk24jh.fsf@toke.dk> <7qQvJLeSZV3rJnkg9rIdA6yznDPzhIFVR_qUa0hBhmCdr_onJsjzXvKVIlp-ovJiRaX1eENGmtrtcZ_7xsHY7heX2qOvouN8pXTt_J3RurQ=@protonmail.ch> From: Christophe-Marie Duquesne Date: Mon, 7 May 2018 15:35:39 +0200 Message-ID: Subject: Re: WG interface to ipv4 To: vtol Content-Type: multipart/alternative; boundary="000000000000137150056b9dc04d" Cc: wireguard List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --000000000000137150056b9dc04d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, May 6, 2018 at 9:39 PM, =D1=BD=D2=89=E1=B6=AC=E1=B8=B3=E2=84=A0 wrote: > With a thread model considering every piece of software being flawed in > mind, and with whatever CVE unearthed being a point in case, it should be > of little surprise that the question of mitigating surface exposure is > raised. Once WG would gain traction beyond a niche app it is likely to be > subjected to malicious attacks with increased frequency. > There is no need for a nob in wireguard to ensure that the wireguard traffic goes through a specific interface or is bound to a specific ip address. You can use iptables if you want to drop packets that are not for the intended interface / ip address. You can disable ipv6 if you don't want ipv6. If you think that wireguard could be flawed, why would you trust this as a wireguard option? If you do not trust it, enforce it from the outside. --000000000000137150056b9dc04d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, May 6, 2018 at 9:39 PM, =D1=BD=D2=89=E1=B6=AC=E1=B8=B3=E2=84=A0= <vt= ol@gmx.net> wrote:
With a thread model considering every piece of software being flawed in min= d, and with whatever CVE unearthed being a point in case, it should be of l= ittle surprise that the question of mitigating surface exposure is raised. = Once WG would gain traction beyond a niche app it is likely to be subjected= to malicious attacks with increased frequency.

There is no need for a nob in wireguard to ensure that the wir= eguard traffic goes through a specific interface or is bound to a specific = ip address. You can use iptables if you want to drop packets that are not f= or the intended interface / ip address. You can disable ipv6 if you don'= ;t want ipv6. If you think that wireguard could be flawed, why would you tr= ust this as a wireguard option? If you do not trust it, enforce it from the= outside.

--000000000000137150056b9dc04d--