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 WireGuard with obfuscation support 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.