<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><blockquote type="cite"><font color="#000000"><span style="caret-color: rgb(0, 0, 0); background-color: rgba(255, 255, 255, 0);">The userspace daemon would:<br> - 'Clean' Wireguard [handshake/data] packets</span></font></blockquote><div><br></div><div>The objective of cleaning as described seems to be to make the protocol indistinguishable from exchanging random payloads. But are there any common protocols 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 —nothing I would hesitate to block (or flag as suspicious) if I were running a big traffic classifier.</div><div><br></div><div>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!). But that doesn’t get you UDP (and NAT traversal); perhaps VOIP/WebRTC mimicry could work?</div><div><br></div><div><br></div><div>Best,</div><div>George</div><div><br></div><div><br></div><div id="AppleMailSignature">Sent from my iPhone</div><div><br>On Sep 6, 2018, at 4:43 AM, Dennis Jackson <<a href="mailto:dennis.jackson@cs.ox.ac.uk">dennis.jackson@cs.ox.ac.uk</a>> wrote:<br><br></div><blockquote type="cite"><div><span>Hi, </span><br><span></span><br><span>I've been thinking about this issue as well and I agree it's an</span><br><span>important one to solve. However, Wireguard's key selling points are its</span><br><span>performance, simple configuration and minimal code size and I don't</span><br><span>think we can compromise this. So I was wondering if a userspace program</span><br><span>which obfuscates outgoing Wireguard packets and de-obfuscates incoming</span><br><span>packets might solve the problem, without impacting Wireguard's key</span><br><span>features. </span><br><span></span><br><span>The userspace daemon would:</span><br><span> - 'Clean' Wireguard handshake packets, </span><br><span> * Randomise the packet type field</span><br><span> * Convert the ephemeral key to Elligator encoding</span><br><span> * Randomise the mac field if unused</span><br><span> * Random padding to alter packet lengths</span><br><span> - 'Clean' Data packets</span><br><span> * The header is exactly 16 bytes and non-repeating so</span><br><span> transform with AES-ECB</span><br><span> * The key could be derived from a PSK and the public</span><br><span> keys used in the handshake (ensuring keys don't</span><br><span> repeat)</span><br><span> * Or Wireguard could provide a hook for a "post-master</span><br><span> secret" which might be useful for many extensions</span><br><span> - The resulting stream would (hopefully) be uniformly</span><br><span> distributed which can either be transmitted directly or</span><br><span> passed to a pluggable transport. </span><br><span> - On the receiving end the daemon reverses the transformation</span><br><span> and delivers the packets to Wireguard.</span><br><span></span><br><span>Outcome:</span><br><span> + Clear separation between codebases</span><br><span> + No matter how badly implemented, the userspace daemon can't</span><br><span> compromise authenticity or confidentiality. </span><br><span> + Easily extensible</span><br><span> + Wireguard doesn't need to know about the transformation, it</span><br><span> just sends its packets to a listener on the loopback</span><br><span> interface.</span><br><span> - Performance hit from the packet indirection, ECB encryption</span><br><span> etc</span><br><span> - Still needs Wireguard to disable cookies, add timing jitter</span><br><span> on handshake / keep-alive packets. </span><br><span></span><br><span>I'm sure there are alternatives/better solutions. This is just a</span><br><span>sketch to show it is possible without altering Wireguard's codebase or</span><br><span>functionality. If you have any comments or criticism, I'd be interested</span><br><span>in refining the idea further. </span><br><span></span><br><span>Kind regards,</span><br><span>Dennis</span><br><span></span><br><span>On Thu, 6 Sep 2018 10:06:07 +1000</span><br><span>StarBrilliant <<a href="mailto:coder@poorlab.com">coder@poorlab.com</a>> wrote:</span><br><span></span><br><blockquote type="cite"><span>Hi,</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>(TL;DR: Please seriously consider preventing WG from being blocked,</span><br></blockquote><blockquote type="cite"><span>for 2/3 of the world's Internet users. No need to break compatibility,</span><br></blockquote><blockquote type="cite"><span>be friendly to PT plugins is a possible solution.)</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I have been using WG for months. I understand the fact that Wireguard</span><br></blockquote><blockquote type="cite"><span>wants to keep its protocol simple and easy to audit. I also understand</span><br></blockquote><blockquote type="cite"><span>that we have talked about this topic back in 2016. [1]</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>## The problem: way too easy to block</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I propose this issue again, because Wireguard has recently become a</span><br></blockquote><blockquote type="cite"><span>hot topic in Chinese community with the most strict</span><br></blockquote><blockquote type="cite"><span><del>Internet</del> Intranet censorship in the world. Chinese</span><br></blockquote><blockquote type="cite"><span>Wireguard users succeeded in access the Internet temporarily, but we</span><br></blockquote><blockquote type="cite"><span>know Wireguard never tries to prevent itself from being blocked.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>It is indeed very easy to completely block Wireguard protocol with</span><br></blockquote><blockquote type="cite"><span>iptables:</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>iptables -A FORWARD -p udp -m length --length 120 -m u32 --u32 "0</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>22 & 0x3c @ 8 = 0x2000000" -j DROP </span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><span>(Yes, from prior experience of blocking TLS and OpenVPN, usually</span><br></blockquote><blockquote type="cite"><span>Message ID 2 is blocked instead of Message ID 1, probably for the</span><br></blockquote><blockquote type="cite"><span>intention to consume server resources.)</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>It is also possible to interfere with the keep-alive packet, since it</span><br></blockquote><blockquote type="cite"><span>is "always on time like a bus" and exactly 32 bytes:</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>iptables -A FORWARD -p udp -m length --length 60 -m u32 --u32 "0 >></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>22 & 0x3c @ 8 = 0x4000000" -m statistic --mode random --probability</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>0.4 -j DROP </span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>## But it's unrelated to WG's security model!</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I heard someone saying something like below:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>On Sat Jul 9 17:49:47 CEST 2016, Bruno Wolff III <<a href="mailto:bruno@wolff.to">bruno@wolff.to</a>></span><br></blockquote><blockquote type="cite"><span>wrote:</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>Given the design goals of wireguard, I don't think it is something</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>that would be particularly good to combine with steganography. We</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>need real net neutrality, with ISPs not allowed to block traffic</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>based on content. We need governments not passing laws to make</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>people compromise their own security. Using strong unbreakable</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>encryption when communicating, should be the norm, not something</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>you need to hide. </span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I interpret those sentences as identical to "Do not use Wireguard if</span><br></blockquote><blockquote type="cite"><span>you live in a country where unlicensed VPN is illegal. Go and ask for</span><br></blockquote><blockquote type="cite"><span>net neutrality instead." But the fact is that 2/3 of the world's</span><br></blockquote><blockquote type="cite"><span>Internet users [2] live in censorship. For most of them, unlicensed</span><br></blockquote><blockquote type="cite"><span>VPN is their only weapon to fight for net neutrality.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>The undoubted top-1 encrypted proxy software [3] in China was not</span><br></blockquote><blockquote type="cite"><span>written by a crypto professional and even started with RC4-MD5, not</span><br></blockquote><blockquote type="cite"><span>until 5 years later (2017) did it have AEAD cipher.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>People love Wireguard because of its security, flexibility and</span><br></blockquote><blockquote type="cite"><span>efficiency, but only when it can work. It is useless to talk about</span><br></blockquote><blockquote type="cite"><span>security if it does not work.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>## Can we solve the problem easily?</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>What makes Wireguard easy to detect?</span><br></blockquote><blockquote type="cite"><span>- Fixed first 4 bytes</span><br></blockquote><blockquote type="cite"><span> (0x01000000 through 0x04000000)</span><br></blockquote><blockquote type="cite"><span>- Plaintext nounce counter</span><br></blockquote><blockquote type="cite"><span> (Could XChaCha20 solve the problem?)</span><br></blockquote><blockquote type="cite"><span>- Fixed sender & receiver ID</span><br></blockquote><blockquote type="cite"><span> (Two-pass encrypt might work, see below)</span><br></blockquote><blockquote type="cite"><span>- Fixed length handshake & keep-alive</span><br></blockquote><blockquote type="cite"><span> (148, 92, 32. can we pad them longer?)</span><br></blockquote><blockquote type="cite"><span>- Punctual rekey & keep-alive</span><br></blockquote><blockquote type="cite"><span> (Can we delay them randomly as IPsec do?)</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>How can we solve the problem?</span><br></blockquote><blockquote type="cite"><span>- Embed steganography inside Wireguard?</span><br></blockquote><blockquote type="cite"><span> (Not realistic. Big codebase, potential bugs.)</span><br></blockquote><blockquote type="cite"><span>- Two-pass encrypt so no more plaintext handshake?</span><br></blockquote><blockquote type="cite"><span> The outer layer could be PSK and does not need to be PFS.</span><br></blockquote><blockquote type="cite"><span> (Possible but slow. PSK can be shared among sessions, like</span><br></blockquote><blockquote type="cite"><span>L2TP/IPsec do.)</span><br></blockquote><blockquote type="cite"><span>- Remain plaintext, but fix padding and timing problem,</span><br></blockquote><blockquote type="cite"><span> relying Pluggable Transport [4] plugins to do the remaining work.</span><br></blockquote><blockquote type="cite"><span> (I really recommend this solution.)</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I read the tech whitepaper multiple times. I think it is possible</span><br></blockquote><blockquote type="cite"><span>solve the problem in Method 3 without breaking any compatibility. For</span><br></blockquote><blockquote type="cite"><span>Message ID = 1, 2, 3, we can add random data at the end of the packet.</span><br></blockquote><blockquote type="cite"><span>For Message ID = 4 and Length = 0 (keep-alive packet), we can add more</span><br></blockquote><blockquote type="cite"><span>zeros in the encapsulated packet. For the timing problem, we can give</span><br></blockquote><blockquote type="cite"><span>rekey and keep-alive a little bit randomness.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>In conclusion, I think we do not need to break the compatibility or</span><br></blockquote><blockquote type="cite"><span>bloat the code base to make Wireguard immune to being detected. We</span><br></blockquote><blockquote type="cite"><span>could either two-pass encrypt the packet, or solve the padding and</span><br></blockquote><blockquote type="cite"><span>timing problem so PT plugins can run on top of it. I hope to see</span><br></blockquote><blockquote type="cite"><span>Wireguard run anywhere without worries, not only on devices owned by</span><br></blockquote><blockquote type="cite"><span>1/3 of the Internet's population.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>## Notes</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>[1] <a href="https://lists.zx2c4.com/pipermail/wireguard/2016-July/000184.html">https://lists.zx2c4.com/pipermail/wireguard/2016-July/000184.html</a></span><br></blockquote><blockquote type="cite"><span>[2] <a href="https://www.theverge.com/2016/11/14/13596974/">https://www.theverge.com/2016/11/14/13596974/</a></span><br></blockquote><blockquote type="cite"><span>[3] <a href="https://github.com/shadowsocks/shadowsocks">https://github.com/shadowsocks/shadowsocks</a> (Please switch git</span><br></blockquote><blockquote type="cite"><span>branch to see the actual code)</span><br></blockquote><blockquote type="cite"><span>[4]</span><br></blockquote><blockquote type="cite"><span><a href="https://www.torproject.org/docs/pluggable-transports.html.en#list-of-pts">https://www.torproject.org/docs/pluggable-transports.html.en#list-of-pts</a></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Best regards.</span><br></blockquote><blockquote type="cite"><span>_______________________________________________</span><br></blockquote><blockquote type="cite"><span>WireGuard mailing list</span><br></blockquote><blockquote type="cite"><span><a href="mailto:WireGuard@lists.zx2c4.com">WireGuard@lists.zx2c4.com</a></span><br></blockquote><blockquote type="cite"><span><a href="https://lists.zx2c4.com/mailman/listinfo/wireguard">https://lists.zx2c4.com/mailman/listinfo/wireguard</a></span><br></blockquote><span></span><br><span></span><br><span></span><br><span>-- </span><br><span>PGP Fingerprint: 5B93 F0B9 D6A8 9BC1 546B C98C 6105 A775 8CD2 46AC</span><br></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>WireGuard mailing list</span><br><span><a href="mailto:WireGuard@lists.zx2c4.com">WireGuard@lists.zx2c4.com</a></span><br><span><a href="https://lists.zx2c4.com/mailman/listinfo/wireguard">https://lists.zx2c4.com/mailman/listinfo/wireguard</a></span><br></div></blockquote></body></html>