From: Roman Mamedov <rm@romanrm.net>
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 12:34:39 +0500 [thread overview]
Message-ID: <20210927123439.7a551913@nvm> (raw)
In-Reply-To: <20210927071130.GA13681@wolff.to>
On Mon, 27 Sep 2021 02:11:30 -0500
Bruno Wolff III <bruno@wolff.to> wrote:
> 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.
>
> This may not be something the developers for Wireguard want to be
> responsible for.
No need to make DPI's job especially easy either.
Don't over-estimate the resources available to DPIs, if there aren't easy
ways to block, it might be almost as good as unblockable.
And it is far from all cases that hiding traffic would result in bad
consequences. Just hiding it enough so it evades the dumb automated filter,
many people will thank you.
As far as I understand right now WireGuard is very vulnerable to being
blocked, due to the fixed 4 bytes at the beginning(?) of each packet. At least
that needs to be randomized/encrypted. Just make the entire packet look like
random noise - that's the sign of good crypto, right? It is even somewhat
surprising as to why that's not the case already.
--
With respect,
Roman
next prev parent reply other threads:[~2021-09-27 7:35 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 [this message]
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
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=20210927123439.7a551913@nvm \
--to=rm@romanrm.net \
--cc=bruno@wolff.to \
--cc=el3xyz@protonmail.com \
--cc=nico.schottelius@ungleich.ch \
--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).