From: Nico Schottelius <nico.schottelius@ungleich.ch>
To: Bruno Wolff III <bruno@wolff.to>
Cc: Nico Schottelius <nico.schottelius@ungleich.ch>,
el3xyz <el3xyz@protonmail.com>,
wireguard@lists.zx2c4.com
Subject: Re: WireGuard with obfuscation support
Date: Mon, 27 Sep 2021 16:44:58 +0900 [thread overview]
Message-ID: <87y27ibgjp.fsf@ungleich.ch> (raw)
In-Reply-To: <20210927071130.GA13681@wolff.to>
Bruno,
thanks for raising 2 very important points:
Bruno Wolff III <bruno@wolff.to> writes:
> On Mon, Sep 27, 2021 at 09:53:08 +0900,
> Nico Schottelius <nico.schottelius@ungleich.ch> wrote:
>>
>>I'd appreciate if wireguard upstream would take this in, maybe even
>>supporting multiple / dynamic listen ports.
>
> The problem is mostly orthogonal to Wireguard. There isn't going to be
> a one size fits all solution for hiding traffic. Failures in hiding
> traffic are potentially very bad for individuals. As such general
> solutions are not something you can recommend universally to people,
> as amateurs are not going to be able to make good decisions about the
> risks and some may get themselves tortured and killed.
1) being able to communicate for non-tech savvy users
This is a very important point, especially a failure to do so might be
critical in reality like you pointed out. So the easier we make it for
non-tech people to "just get it working", many more life's will be saved
from torture. Because the alternative are insecure communication channels.
> This may not be something the developers for Wireguard want to be
> responsible for.
2) The responsibility of software developers
As usual with GPL/similar licenses, software is provided AS-IS. We are
not selling a "fully autonomous car" here that is actually not able to
drive on its own, but instead giving a warranty free software to people.
It's important to raise these points, but from what I can see the easier
we make it for people to securely communicate, the less likely threats
arrive.
Outside of the scope of wireguard I see tunnel combinations like moving
wireguard traffic through udp+tcp/53, tcp/80+443, which are also
interesting options, but are probably solved with other tunneling tools.
Cheers,
Nico
--
Sustainable and modern Infrastructures by ungleich.ch
next prev parent reply other threads:[~2021-09-27 7:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-26 12:09 el3xyz
2021-09-27 0:53 ` Nico Schottelius
2021-09-27 7:11 ` Bruno Wolff III
2021-09-27 7:34 ` Roman Mamedov
2021-09-27 9:14 ` Bruno Wolff III
2021-09-27 9:36 ` Roman Mamedov
2021-09-27 10:21 ` Bruno Wolff III
2021-09-27 13:01 ` Konstantin Ryabitsev
2021-09-27 13:48 ` Lonnie Abelbeck
2021-09-27 15:28 ` StarBrilliant
2021-09-27 15:59 ` Nico Schottelius
2021-09-27 16:37 ` StarBrilliant
2021-09-27 7:44 ` Nico Schottelius [this message]
2021-09-27 8:17 ` Fredrik Strömberg
2021-09-27 16:21 ` Jason A. Donenfeld
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y27ibgjp.fsf@ungleich.ch \
--to=nico.schottelius@ungleich.ch \
--cc=bruno@wolff.to \
--cc=el3xyz@protonmail.com \
--cc=wireguard@lists.zx2c4.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).