From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: georgewalkeriv@gmail.com Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 236d0589 for ; Thu, 6 Sep 2018 14:45:13 +0000 (UTC) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 70c82a3b for ; Thu, 6 Sep 2018 14:45:13 +0000 (UTC) Received: by mail-qk1-x72e.google.com with SMTP id f62-v6so5754043qke.2 for ; Thu, 06 Sep 2018 07:45:27 -0700 (PDT) Return-Path: Content-Type: multipart/alternative; boundary=Apple-Mail-2E805334-1C08-472E-B2DC-2BEA89008C95 Mime-Version: 1.0 (1.0) Subject: Re: Let's talk about obfuscation again From: George Walker In-Reply-To: <20180906094330.273b07be@T-200> Date: Thu, 6 Sep 2018 10:45:24 -0400 Message-Id: <706D2A48-7DAA-436A-BB99-2AE80822B524@gmail.com> References: <20180906094330.273b07be@T-200> To: Dennis Jackson Cc: wireguard@lists.zx2c4.com List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --Apple-Mail-2E805334-1C08-472E-B2DC-2BEA89008C95 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > The userspace daemon would: > - 'Clean' Wireguard [handshake/data] packets The objective of cleaning as described seems to be to make the protocol indi= stinguishable from exchanging random payloads. But are there any common prot= ocols of commercial importance that are so inscrutable? If I saw such random= -looking UDP payloads on the wire I would suspect malware c&c, file sharing (= who remembers FreeNet?), or a tunnel, depending on data volume and direction= =E2=80=94nothing I would hesitate to block (or flag as suspicious) if I wer= e running a big traffic classifier. Domain fronting seems like the stealthiest option to me (and if anyone has a= reliable way to detect domain fronting, I would love to hear about it!). Bu= t that doesn=E2=80=99t get you UDP (and NAT traversal); perhaps VOIP/WebRTC m= imicry could work? Best, George Sent from my iPhone > On Sep 6, 2018, at 4:43 AM, Dennis Jackson wr= ote: >=20 > Hi,=20 >=20 > I've been thinking about this issue as well and I agree it's an > important one to solve. However, Wireguard's key selling points are its > performance, simple configuration and minimal code size and I don't > think we can compromise this. So I was wondering if a userspace program > which obfuscates outgoing Wireguard packets and de-obfuscates incoming > packets might solve the problem, without impacting Wireguard's key > features.=20 >=20 > The userspace daemon would: > - 'Clean' Wireguard handshake packets,=20 > * Randomise the packet type field > * Convert the ephemeral key to Elligator encoding > * Randomise the mac field if unused > * Random padding to alter packet lengths > - 'Clean' Data packets > * The header is exactly 16 bytes and non-repeating so > transform with AES-ECB > * The key could be derived from a PSK and the public > keys used in the handshake (ensuring keys don't > repeat) > * Or Wireguard could provide a hook for a "post-master > secret" which might be useful for many extensions > - The resulting stream would (hopefully) be uniformly > distributed which can either be transmitted directly or > passed to a pluggable transport.=20 > - On the receiving end the daemon reverses the transformation > and delivers the packets to Wireguard. >=20 > Outcome: > + Clear separation between codebases > + No matter how badly implemented, the userspace daemon can't > compromise authenticity or confidentiality.=20 > + Easily extensible > + Wireguard doesn't need to know about the transformation, it > just sends its packets to a listener on the loopback > interface. > - Performance hit from the packet indirection, ECB encryption > etc > - Still needs Wireguard to disable cookies, add timing jitter > on handshake / keep-alive packets.=20 >=20 > I'm sure there are alternatives/better solutions. This is just a > sketch to show it is possible without altering Wireguard's codebase or > functionality. If you have any comments or criticism, I'd be interested > in refining the idea further.=20 >=20 > Kind regards, > Dennis >=20 > On Thu, 6 Sep 2018 10:06:07 +1000 > StarBrilliant wrote: >=20 >> Hi, >>=20 >> (TL;DR: Please seriously consider preventing WG from being blocked, >> for 2/3 of the world's Internet users. No need to break compatibility, >> be friendly to PT plugins is a possible solution.) >>=20 >> I have been using WG for months. I understand the fact that Wireguard >> wants to keep its protocol simple and easy to audit. I also understand >> that we have talked about this topic back in 2016. [1] >>=20 >>=20 >> ## The problem: way too easy to block >>=20 >> I propose this issue again, because Wireguard has recently become a >> hot topic in Chinese community with the most strict >> Internet Intranet censorship in the world. Chinese >> Wireguard users succeeded in access the Internet temporarily, but we >> know Wireguard never tries to prevent itself from being blocked. >>=20 >> It is indeed very easy to completely block Wireguard protocol with >> iptables: >>> iptables -A FORWARD -p udp -m length --length 120 -m u32 --u32 "0 >>>>> 22 & 0x3c @ 8 =3D 0x2000000" -j DROP =20 >> (Yes, from prior experience of blocking TLS and OpenVPN, usually >> Message ID 2 is blocked instead of Message ID 1, probably for the >> intention to consume server resources.) >>=20 >> It is also possible to interfere with the keep-alive packet, since it >> is "always on time like a bus" and exactly 32 bytes: >>> iptables -A FORWARD -p udp -m length --length 60 -m u32 --u32 "0 >> >>> 22 & 0x3c @ 8 =3D 0x4000000" -m statistic --mode random --probability >>> 0.4 -j DROP =20 >>=20 >>=20 >> ## But it's unrelated to WG's security model! >>=20 >> I heard someone saying something like below: >>=20 >> On Sat Jul 9 17:49:47 CEST 2016, Bruno Wolff III >> wrote: >>> Given the design goals of wireguard, I don't think it is something >>> that would be particularly good to combine with steganography. We >>> need real net neutrality, with ISPs not allowed to block traffic >>> based on content. We need governments not passing laws to make >>> people compromise their own security. Using strong unbreakable >>> encryption when communicating, should be the norm, not something >>> you need to hide. =20 >>=20 >> I interpret those sentences as identical to "Do not use Wireguard if >> you live in a country where unlicensed VPN is illegal. Go and ask for >> net neutrality instead." But the fact is that 2/3 of the world's >> Internet users [2] live in censorship. For most of them, unlicensed >> VPN is their only weapon to fight for net neutrality. >>=20 >> The undoubted top-1 encrypted proxy software [3] in China was not >> written by a crypto professional and even started with RC4-MD5, not >> until 5 years later (2017) did it have AEAD cipher. >>=20 >> People love Wireguard because of its security, flexibility and >> efficiency, but only when it can work. It is useless to talk about >> security if it does not work. >>=20 >>=20 >> ## Can we solve the problem easily? >>=20 >> What makes Wireguard easy to detect? >> - Fixed first 4 bytes >> (0x01000000 through 0x04000000) >> - Plaintext nounce counter >> (Could XChaCha20 solve the problem?) >> - Fixed sender & receiver ID >> (Two-pass encrypt might work, see below) >> - Fixed length handshake & keep-alive >> (148, 92, 32. can we pad them longer?) >> - Punctual rekey & keep-alive >> (Can we delay them randomly as IPsec do?) >>=20 >> How can we solve the problem? >> - Embed steganography inside Wireguard? >> (Not realistic. Big codebase, potential bugs.) >> - Two-pass encrypt so no more plaintext handshake? >> The outer layer could be PSK and does not need to be PFS. >> (Possible but slow. PSK can be shared among sessions, like >> L2TP/IPsec do.) >> - Remain plaintext, but fix padding and timing problem, >> relying Pluggable Transport [4] plugins to do the remaining work. >> (I really recommend this solution.) >>=20 >> I read the tech whitepaper multiple times. I think it is possible >> solve the problem in Method 3 without breaking any compatibility. For >> Message ID =3D 1, 2, 3, we can add random data at the end of the packet. >> For Message ID =3D 4 and Length =3D 0 (keep-alive packet), we can add mor= e >> zeros in the encapsulated packet. For the timing problem, we can give >> rekey and keep-alive a little bit randomness. >>=20 >> In conclusion, I think we do not need to break the compatibility or >> bloat the code base to make Wireguard immune to being detected. We >> could either two-pass encrypt the packet, or solve the padding and >> timing problem so PT plugins can run on top of it. I hope to see >> Wireguard run anywhere without worries, not only on devices owned by >> 1/3 of the Internet's population. >>=20 >>=20 >> ## Notes >>=20 >> [1] https://lists.zx2c4.com/pipermail/wireguard/2016-July/000184.html >> [2] https://www.theverge.com/2016/11/14/13596974/ >> [3] https://github.com/shadowsocks/shadowsocks (Please switch git >> branch to see the actual code) >> [4] >> https://www.torproject.org/docs/pluggable-transports.html.en#list-of-pts >>=20 >>=20 >> Best regards. >> _______________________________________________ >> WireGuard mailing list >> WireGuard@lists.zx2c4.com >> https://lists.zx2c4.com/mailman/listinfo/wireguard >=20 >=20 >=20 > --=20 > PGP Fingerprint: 5B93 F0B9 D6A8 9BC1 546B C98C 6105 A775 8CD2 46AC > _______________________________________________ > WireGuard mailing list > WireGuard@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/wireguard --Apple-Mail-2E805334-1C08-472E-B2DC-2BEA89008C95 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The userspace daemon would:
   - 'Clean' Wiregu= ard [handshake/data] packets

T= he objective of cleaning as described seems to be to make the protocol indis= tinguishable from exchanging random payloads. But are there any common proto= cols of commercial importance that are so inscrutable? If I saw such random-= looking UDP payloads on the wire I would suspect malware c&c, file shari= ng (who remembers FreeNet?), or a tunnel, depending on data volume and direc= tion =E2=80=94nothing I would hesitate to block (or flag as suspicious) if I= were running a big traffic classifier.

Domain fron= ting seems like the stealthiest option to me (and if anyone has a reliable w= ay to detect domain fronting, I would love to hear about it!). But that does= n=E2=80=99t get you UDP (and NAT traversal); perhaps VOIP/WebRTC mimicry cou= ld work?


Best,
George


Sent from my i= Phone

On Sep 6, 2018, at 4:43 AM, Dennis Jackson <dennis.jackson@cs.ox.ac.uk> wrote= :

Hi,

I've been thinking about this issue as well and I agree it's a= n
important one to solve. However, Wireguard's key selling p= oints are its
performance, simple configuration and minimal c= ode size and I don't
think we can compromise this. So I was w= ondering if a userspace program
which obfuscates outgoing Wi= reguard packets and de-obfuscates incoming
packets might sol= ve the problem, without impacting Wireguard's key
features. <= /span>

The userspace daemon would:
   - 'Clean' Wireguard handshake packets,
&nbs= p;      * Randomise the packet type field
&n= bsp;      * Convert the ephemeral key to Elligator encoding
       * Randomise the mac field if unus= ed
       * Random padding to alter pac= ket lengths
   - 'Clean' Data packets
<= span>        * The header is exactly 16 bytes and non-re= peating so
         transform with= AES-ECB
       * The key could be deri= ved from a PSK and the public
        &= nbsp;keys used in the handshake (ensuring keys don't
 =        repeat)
      &n= bsp;* Or Wireguard could provide a hook for a "post-master
&= nbsp;        secret" which might be useful for many exte= nsions
   - The resulting stream would (hopefully= ) be uniformly
     distributed which can ei= ther be transmitted directly or
     passed t= o a pluggable transport.
   - On the receiving e= nd the daemon reverses the transformation
    &nb= sp;and delivers the packets to Wireguard.

O= utcome:
   + Clear separation between codebases
   + No matter how badly implemented, the userspac= e daemon can't
     compromise authenticity o= r confidentiality.
   + Easily extensible=
   + Wireguard doesn't need to know about the transform= ation, it
     just sends its packets to a l= istener on the loopback
     interface.
   - Performance hit from the packet indirection, ECB= encryption
     etc
 =  - Still needs Wireguard to disable cookies, add timing jitter<= br>      on handshake / keep-alive packets.
=
I'm sure there are alternatives/better solutions. Thi= s is just a
sketch to show it is possible without altering W= ireguard's codebase or
functionality. If you have any commen= ts or criticism, I'd be interested
in refining the idea furt= her.

Kind regards,
Dennis<= /span>

On Thu, 6 Sep 2018 10:06:07 +1000StarBrilliant <coder@poorlab.= com> wrote:

Hi,

(TL;DR: Please seriously consider p= reventing WG from being blocked,
for 2/3 of the world's Internet users. No need to break compatib= ility,
be friendly to= PT plugins is a possible solution.)

I ha= ve been using WG for months. I understand the fact that Wireguard
=
wants to keep its protocol simp= le and easy to audit. I also understand
that we have talked about this topic back in 2016. [1]


## The problem: way too easy to block

I propose this issue again, because Wireguard has recently become a=
hot topic in Chinese= community with the most strict
<del>Internet</del> Intranet censorship in the world.= Chinese
Wireguard us= ers succeeded in access the Internet temporarily, but we
know Wireguard never tries to prevent it= self from being blocked.

It is indeed ver= y easy to completely block Wireguard protocol with
iptables:
iptables -A FORWARD -p udp -m l= ength --length 120 -m u32 --u32 "0
22 & 0x3c @ 8 =3D 0x2000000" -j DROP  =
(Yes, from prior experience of blocking TLS and OpenVPN, u= sually
Message ID 2 i= s blocked instead of Message ID 1, probably for the
<= blockquote type=3D"cite">intention to consume server resources.)

It is also possible to interfere with the keep= -alive packet, since it
is "always on time like a bus" and exactly 32 bytes:
iptables -A FOR= WARD -p udp -m length --length 60 -m u32 --u32 "0 >>
22 & 0x3c @ 8 =3D 0x4000000" -m statistic --mode random --probability
0.4 -j DROP  


## But it's u= nrelated to WG's security model!

I heard s= omeone saying something like below:

On Sat J= ul 9 17:49:47 CEST 2016, Bruno Wolff III <bruno@wolff.to>
<= span>wrote:
Given the design goals of wireguard, I don't think it is so= mething
that would be particularly good to combine with st= eganography. We
need real net neutrality, with ISPs not al= lowed to block traffic
based on content. We need governments= not passing laws to make
people compromise their own secu= rity. Using strong unbreakable
encryption when communicati= ng, should be the norm, not something
you need to hide. &n= bsp;

I interpret those sente= nces as identical to "Do not use Wireguard if
you live in a country where unlicensed VPN is illeg= al. Go and ask for
ne= t neutrality instead." But the fact is that 2/3 of the world's
Internet users [2] live in censors= hip. For most of them, unlicensed
VPN is their only weapon to fight for net neutrality.

The undoubted top-1 encrypted proxy software [3] i= n China was not
writt= en by a crypto professional and even started with RC4-MD5, not
until 5 years later (2017) did it h= ave AEAD cipher.

People love Wireguard be= cause of its security, flexibility and
efficiency, but only when it can work. It is useless to ta= lk about
security if i= t does not work.


=
## Can we solve the problem easily?

What makes Wireguard easy to detect?
- Fixed first 4 bytes
<= /blockquote>
 (0x01000000 through 0x040= 00000)
- Plaintext no= unce counter
 (= Could XChaCha20 solve the problem?)
- Fixed sender & receiver ID
 (Two-pass encrypt might work, see below)
- Fixed length handshake= & keep-alive
&n= bsp;(148, 92, 32. can we pad them longer?)
- Punctual rekey & keep-alive
 (Can we delay them randomly as IPs= ec do?)

How can we solve the problem?
- Embed steganography in= side Wireguard?
&nbs= p;(Not realistic. Big codebase, potential bugs.)
- Two-pass encrypt so no more plaintext handshak= e?
 The outer l= ayer could be PSK and does not need to be PFS.
 (Possible but slow. PSK can be shared among= sessions, like
L2TP/= IPsec do.)
- Remain p= laintext, but fix padding and timing problem,
 relying Pluggable Transport [4] plugins to d= o the remaining work.
 (I really recommend this solution.)

I read the tech whitepaper multiple times. I think it is possible<= br>
solve the problem in Method 3= without breaking any compatibility. For
Message ID =3D 1, 2, 3, we can add random data at the end= of the packet.
For M= essage ID =3D 4 and Length =3D 0 (keep-alive packet), we can add more=
zeros in the encapsulated p= acket. For the timing problem, we can give
rekey and keep-alive a little bit randomness.

In conclusion, I think we do not need to break th= e compatibility or
bl= oat the code base to make Wireguard immune to being detected. We
<= /blockquote>
could either two-pass encrypt th= e packet, or solve the padding and
timing problem so PT plugins can run on top of it. I hope to se= e
Wireguard run anywh= ere without worries, not only on devices owned by
1/3 of the Internet's population.


## Notes
[1] https://lists.zx2c4.com/= pipermail/wireguard/2016-July/000184.html
[2] https://www.theverge.com/2016/11/14/13596974/
[3] https://github.com/shadowsocks/shadowsocks (Pleas= e switch git
branch t= o see the actual code)
[4]
https:= //www.torproject.org/docs/pluggable-transports.html.en#list-of-pts


Best regards.
_______________________________________________
WireGuard mailing list
=
WireGuard@lists.zx2c4.com
htt= ps://lists.zx2c4.com/mailman/listinfo/wireguard
<= span>


--
= PGP Fingerprint: 5B93 F0B9 D6A8 9BC1 546B C98C 6105 A775 8CD2 46AC
___________________= ____________________________
WireGuard mailing listWireGuard@lists.zx2c4.c= om
https://lists.zx2c4.com/mailman/listinfo/wireguard
<= /div>
= --Apple-Mail-2E805334-1C08-472E-B2DC-2BEA89008C95--