* Let's talk about obfuscation again @ 2018-09-06 0:06 StarBrilliant 2018-09-06 8:43 ` Dennis Jackson 2018-09-06 16:10 ` Jason A. Donenfeld 0 siblings, 2 replies; 9+ messages in thread From: StarBrilliant @ 2018-09-06 0:06 UTC (permalink / raw) To: wireguard Hi, (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.) 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] ## 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 users succeeded in access the Internet temporarily, but we know Wireguard never tries to prevent itself from being blocked. 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 = 0x2000000" -j DROP (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.) 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 = 0x4000000" -m statistic --mode random --probability 0.4 -j DROP ## But it's unrelated to WG's security model! I heard someone saying something like below: On Sat Jul 9 17:49:47 CEST 2016, Bruno Wolff III <bruno@wolff.to> 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. 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. 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. 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. ## Can we solve the problem easily? 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?) 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.) 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 = 1, 2, 3, we can add random data at the end of the packet. For Message ID = 4 and Length = 0 (keep-alive packet), we can add more zeros in the encapsulated packet. 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 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. ## 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 (Please switch git branch to see the actual code) [4] https://www.torproject.org/docs/pluggable-transports.html.en#list-of-pts Best regards. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Let's talk about obfuscation again 2018-09-06 0:06 Let's talk about obfuscation again StarBrilliant @ 2018-09-06 8:43 ` Dennis Jackson 2018-09-06 14:45 ` George Walker 2018-09-06 16:10 ` Jason A. Donenfeld 1 sibling, 1 reply; 9+ messages in thread From: Dennis Jackson @ 2018-09-06 8:43 UTC (permalink / raw) To: wireguard [-- Attachment #1: Type: text/plain, Size: 7357 bytes --] Hi, 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. The userspace daemon would: - 'Clean' Wireguard handshake packets, * 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. - On the receiving end the daemon reverses the transformation and delivers the packets to Wireguard. Outcome: + Clear separation between codebases + No matter how badly implemented, the userspace daemon can't compromise authenticity or confidentiality. + 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. 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. Kind regards, Dennis On Thu, 6 Sep 2018 10:06:07 +1000 StarBrilliant <coder@poorlab.com> wrote: > Hi, > > (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.) > > 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] > > > ## 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 users succeeded in access the Internet temporarily, but we > know Wireguard never tries to prevent itself from being blocked. > > 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 = 0x2000000" -j DROP > (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.) > > 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 = 0x4000000" -m statistic --mode random --probability > > 0.4 -j DROP > > > ## But it's unrelated to WG's security model! > > I heard someone saying something like below: > > On Sat Jul 9 17:49:47 CEST 2016, Bruno Wolff III <bruno@wolff.to> > 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. > > 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. > > 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. > > 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. > > > ## Can we solve the problem easily? > > 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?) > > 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.) > > 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 = 1, 2, 3, we can add random data at the end of the packet. > For Message ID = 4 and Length = 0 (keep-alive packet), we can add more > zeros in the encapsulated packet. 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 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. > > > ## 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 (Please switch git > branch to 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 > https://lists.zx2c4.com/mailman/listinfo/wireguard -- PGP Fingerprint: 5B93 F0B9 D6A8 9BC1 546B C98C 6105 A775 8CD2 46AC [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Let's talk about obfuscation again 2018-09-06 8:43 ` Dennis Jackson @ 2018-09-06 14:45 ` George Walker 2018-09-06 15:19 ` Fredrik Strömberg 2018-09-06 15:34 ` Dennis Jackson 0 siblings, 2 replies; 9+ messages in thread From: George Walker @ 2018-09-06 14:45 UTC (permalink / raw) To: Dennis Jackson; +Cc: wireguard [-- Attachment #1: Type: text/plain, Size: 8770 bytes --] > The userspace daemon would: > - 'Clean' Wireguard [handshake/data] packets 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. 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? Best, George Sent from my iPhone > 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 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. > > The userspace daemon would: > - 'Clean' Wireguard handshake packets, > * 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. > - On the receiving end the daemon reverses the transformation > and delivers the packets to Wireguard. > > Outcome: > + Clear separation between codebases > + No matter how badly implemented, the userspace daemon can't > compromise authenticity or confidentiality. > + 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. > > 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. > > Kind regards, > Dennis > > On Thu, 6 Sep 2018 10:06:07 +1000 > StarBrilliant <coder@poorlab.com> wrote: > >> Hi, >> >> (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.) >> >> 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] >> >> >> ## 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 users succeeded in access the Internet temporarily, but we >> know Wireguard never tries to prevent itself from being blocked. >> >> 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 = 0x2000000" -j DROP >> (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.) >> >> 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 = 0x4000000" -m statistic --mode random --probability >>> 0.4 -j DROP >> >> >> ## But it's unrelated to WG's security model! >> >> I heard someone saying something like below: >> >> On Sat Jul 9 17:49:47 CEST 2016, Bruno Wolff III <bruno@wolff.to> >> 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. >> >> 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. >> >> 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. >> >> 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. >> >> >> ## Can we solve the problem easily? >> >> 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?) >> >> 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.) >> >> 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 = 1, 2, 3, we can add random data at the end of the packet. >> For Message ID = 4 and Length = 0 (keep-alive packet), we can add more >> zeros in the encapsulated packet. 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 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. >> >> >> ## 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 (Please switch git >> branch to 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 >> https://lists.zx2c4.com/mailman/listinfo/wireguard > > > > -- > 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 [-- Attachment #2: Type: text/html, Size: 17665 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Let's talk about obfuscation again 2018-09-06 14:45 ` George Walker @ 2018-09-06 15:19 ` Fredrik Strömberg 2018-09-07 8:49 ` StarBrilliant 2018-09-06 15:34 ` Dennis Jackson 1 sibling, 1 reply; 9+ messages in thread From: Fredrik Strömberg @ 2018-09-06 15:19 UTC (permalink / raw) To: WireGuard mailing list Hi everyone, First of all, censorship circumvention is an important societal problem to solve. It is also clearly outside of the scope of WireGuard. Any suggested protocol change with that motive will increase the complexity of the code base, which increases the risk of vulnerabilities. This would hurt all WireGuard users. Secondly, the experience from Tor's Pluggable Transports, Psiphon, Lantern, and various VPN services, clearly shows that DPI circumvention methods need to be updated regularly. Whatever ideas you have will be fingerprinted and blocked eventually. Using Pluggable Transports seem like a good solution. Simply divert WireGuard traffic to a local UDP port, which then sends it using a Pluggable Transport over the Internet to the other WireGuard peer. StarBrilliant: You indicated that some aspect of WireGuard ("solve the padding and timing problem so PT plugins can run on top of it") prevents Pluggable Transports from working. Please elaborate. Cheers, Fredrik Stromberg On Thu, Sep 6, 2018 at 4:45 PM, George Walker <georgewalkeriv@gmail.com> wr= ote: > The userspace daemon would: > - 'Clean' Wireguard [handshake/data] packets > > > The objective of cleaning as described seems to be to make the protocol > indistinguishable from exchanging random payloads. But are there any comm= on > 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 a= nd > direction =E2=80=94nothing I would hesitate to block (or flag as suspicio= us) if I > were running a big traffic classifier. > > Domain fronting seems like the stealthiest option to me (and if anyone ha= s a > reliable way to detect domain fronting, I would love to hear about it!). = But > that doesn=E2=80=99t get you UDP (and NAT traversal); perhaps VOIP/WebRTC= mimicry > could work? > > > Best, > George > > > Sent from my iPhone > > 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 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. > > The userspace daemon would: > - 'Clean' Wireguard handshake packets, > * 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. > - On the receiving end the daemon reverses the transformation > and delivers the packets to Wireguard. > > Outcome: > + Clear separation between codebases > + No matter how badly implemented, the userspace daemon can't > compromise authenticity or confidentiality. > + 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. > > 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. > > Kind regards, > Dennis > > On Thu, 6 Sep 2018 10:06:07 +1000 > StarBrilliant <coder@poorlab.com> wrote: > > Hi, > > > (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.) > > > 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] > > > > ## 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 users succeeded in access the Internet temporarily, but we > > know Wireguard never tries to prevent itself from being blocked. > > > 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 > > (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.) > > > 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 > > > > ## But it's unrelated to WG's security model! > > > I heard someone saying something like below: > > > On Sat Jul 9 17:49:47 CEST 2016, Bruno Wolff III <bruno@wolff.to> > > 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. > > > 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. > > > 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. > > > 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. > > > > ## Can we solve the problem easily? > > > 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?) > > > 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.) > > > 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. > > > 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. > > > > ## 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 (Please switch git > > branch to 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 > > https://lists.zx2c4.com/mailman/listinfo/wireguard > > > > > -- > 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 > > > _______________________________________________ > WireGuard mailing list > WireGuard@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/wireguard > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Let's talk about obfuscation again 2018-09-06 15:19 ` Fredrik Strömberg @ 2018-09-07 8:49 ` StarBrilliant 0 siblings, 0 replies; 9+ messages in thread From: StarBrilliant @ 2018-09-07 8:49 UTC (permalink / raw) To: Fredrik Strömberg, Jason A. Donenfeld; +Cc: wireguard On Fri, Sep 7, 2018 at 1:20 AM Fredrik Str=C3=B6mberg <stromberg@mullvad.ne= t> wrote: > Using Pluggable Transports seem like a good solution. Simply divert > WireGuard traffic to a local UDP port, which then sends it using a > Pluggable Transport over the Internet to the other WireGuard peer. > > StarBrilliant: You indicated that some aspect of WireGuard ("solve the > padding and timing problem so PT plugins can run on top of it") > prevents Pluggable Transports from working. Please elaborate. On Fri, Sep 7, 2018 at 2:11 AM Jason A. Donenfeld <Jason@zx2c4.com> wrote: > This is generally what I'd recommend too, but I'm not sure I follow > the logic of the padding and timing. Should not a proper pluggable > transport be doing this on its own already? Adding random padding to > all packets, and delaying statistically similar ones randomly as well? > Especially for the padding aspect, there's little reason why a > pluggable transport should not already be doing this. Hello everyone, Thank you for your attention. I will address the two questions above togeth= er. We assume Pluggable Transport to be a universal plug-in. (I don't talk of *a specific* Pluggable Transport program here, because as I already knew, there aren't any PT that supports UDP yet. We will still need to build a UDP-supported PT in the future.) A Pluggable Transport can and should: - Scramble the data so it looks like another protocol or random noise. - Combine and split packets so 1 packet can be 2, 2 can be 1. - Pad the data so the packet length is not identical to the original. - Apply delay & jitter so packets does not follow a uniform temporal pattern. (Sadly, experiments show reordering would terribly affect the TCP performance in a VPN so we would not turn delay & jitter on by default) But a Pluggable Transport CAN NOT: - Identify whether the inner protocol is Wireguard or SSH or Tor. - Have knowledge that the "Client Handshake" length=3D148, the "Server Handshake" length=3D92, the "Keep Alive" length=3D32. - Swallow any of the packet based on the inside of the packet, except for traffic shaping & rate limiting. - Pad the packet too long. (e.g. don't expect 32 -> 1472) - Delay a packets for minutes long, it can only operate on milliseconds lev= el. We know even on an idle connection, the "Client Handshake" is sent every X minutes, immediately followed by a "Server Handshake". And "Keep Alive" is sent every Y minutes (configurable by the user, used for NAT scenarios). I hope three changes applied to Wireguard: - For "Client Handshake", "Server Handshake" and "Keep Alive", since they can be pad to any length without affecting compatibility, why not pad them to any length below 1472? - For data packets, leave them as is and let PT do the padding. - The rekey and keep-alive are sent in random(X-D, X) time, and the server expect a rekey in a window of range(0, X). D can be as long as minutes or as long as 50% of X. - Allow Wireguard to bind to only one or more specific local addresses (e.g. only ::1). Therefore we do not need to use complicated firewall setup to prevent WG from directly expose to the Internet. Best regards. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Let's talk about obfuscation again 2018-09-06 14:45 ` George Walker 2018-09-06 15:19 ` Fredrik Strömberg @ 2018-09-06 15:34 ` Dennis Jackson 1 sibling, 0 replies; 9+ messages in thread From: Dennis Jackson @ 2018-09-06 15:34 UTC (permalink / raw) To: George Walker; +Cc: wireguard [-- Attachment #1: Type: text/plain, Size: 2182 bytes --] On Thu, 6 Sep 2018 17:19:57 +0200 Fredrik Strömberg <stromberg@mullvad.net> wrote: >> First of all, censorship circumvention is an important societal >> problem to solve. It is also clearly outside of the scope of >> WireGuard. Any suggested protocol change with that motive will >> increase the complexity of the code base, which increases the risk >> of vulnerabilities. This would hurt all WireGuard users. Amen! On Thu, 6 Sep 2018 10:45:24 -0400 George Walker <georgewalkeriv@gmail.com> wrote: > 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. There is a few different purposes served by this transform: a) By having a uniformly random stream, its much easier to plug in to various mimicry tools (as you suggest) since you know the input data doesn't contain any meaning. There's some good work from the Tor people on this kind of thing. For example, 'cleaned' traffic could be made to look like TLS, without doubly encrypting every packet with the TLS key, instead the UDP data can be passed through directly. b) From a surveillance perspective, it becomes harder to identify and record traffic. The classification goes from being "WG-VPN" to "???". This makes the analysts job a bit harder. Increasing labour costs is probably more painful for such entities than anything else. c) It forces a censor to move from a blacklisting approach to a whitelisting approach. As you say, this won't stymie the great firewall of China but developing a rule to block traffic which looks "too random" without too many false positives requires a lot of resources and we can exploit this. Best, Dennis -- PGP Fingerprint: 5B93 F0B9 D6A8 9BC1 546B C98C 6105 A775 8CD2 46AC [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Let's talk about obfuscation again 2018-09-06 0:06 Let's talk about obfuscation again StarBrilliant 2018-09-06 8:43 ` Dennis Jackson @ 2018-09-06 16:10 ` Jason A. Donenfeld 1 sibling, 0 replies; 9+ messages in thread From: Jason A. Donenfeld @ 2018-09-06 16:10 UTC (permalink / raw) To: coder; +Cc: WireGuard mailing list Hey SB, Thanks for the detailed post and insights. Indeed obfuscation is an extremely useful tool. WireGuard itself is derived from an exfiltration mechanism of mine, and so I've written quite a few different obfuscation modules for that. When the core WireGuard engineering becomes a bit more relaxed (right now it's pretty intense), I may devote some effort into cleaning these up and making them available as generic methods for whatever packet flow. One thing to consider with obfuscation is: what type do you need and for what purpose? What is your adversary like, and what policies are they trying to enforce? For example, any one of these methods are useful in a particular circumstance: - Turn the entire stream into noise with something like xchacha or aes-pmac-siv. - Turn the stream into noise and then walk a markov chain to generate something that looks like HTML. - Turn the stream into noise and then walk a markov chain to generate something that looks like h264. - Turn the stream into noise and then walk a markov chain to generate something that looks like TLS 1.0. - Turn the stream into noise and then encode the traffic as DNS requests. - Turn the stream into noise and then walk a markov chain to generate something that looks like DNS. - Generate a training set using traffic gathered from eth0, turn the stream into noise, and then use the training set to generate traffic that looks like normal traffic. - Generate a training set using traffic gathered from an implant on another box, turn the stream into noise, and then use the training set to generate traffic that looks like normal traffic. - Manually provide a hand crafted training set, turn the stream into noise, and then use the training set to generate traffic that looks like normal traffic. - Turn the stream into noise, and manually encode that into some given format. - Turn the stream into noise, and then inject as corrupt ethernet frames. - Turn the stream into noise, and then delay existing packets with a modulated encoding to create a side channel. The list goes on. These have all been useful in different circumstances, and there are many more like them. I'm not too familiar with the pluggable transports project, but my understanding is that it is motivated by precisely this insight: there are many valid and useful means of obfuscation, each of which is useful and has different trade-offs. So why not make it pluggable? I generally don't like mega-abstracted and pluggable big complicated things, as a general taste, but here I think one has a decent argument as to why this might make sense. So of your suggestions, the most compelling one is: > - Remain plaintext, but fix padding and timing problem, > relying Pluggable Transport [4] plugins to do the remaining work. > (I really recommend this solution.) This is generally what I'd recommend too, but I'm not sure I follow the logic of the padding and timing. Should not a proper pluggable transport be doing this on its own already? Adding random padding to all packets, and delaying statistically similar ones randomly as well? Especially for the padding aspect, there's little reason why a pluggable transport should not already be doing this. Jason ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <mailman.1542.1536245115.2201.wireguard@lists.zx2c4.com>]
* Re: Let's talk about obfuscation again [not found] <mailman.1542.1536245115.2201.wireguard@lists.zx2c4.com> @ 2018-09-06 15:24 ` Brian Candler 2018-09-06 21:16 ` James Cloos 0 siblings, 1 reply; 9+ messages in thread From: Brian Candler @ 2018-09-06 15:24 UTC (permalink / raw) To: wireguard > 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? I think this is a game you can't win against a suitably motivated adversary. Such an adversary can and will decode the payload to see if it makes sense. For example: an apparently unencrypted VOIP/WebRTC stream, but one which contains "random" payload (i.e. which doesn't decode properly through the declared codec, or decodes to noise) may be interpreted as an encrypted phone call, and blocked on that basis alone, even if it's not obvious it contains data. It would also be massively inefficient. On the one hand, you'd have to send a stream of padding packets when there is no data to send, to look like an idle phone/video call. On the other hand, when you *do* have data to send, you would have to constrain your bandwidth so you don't burst above a level of traffic which such a call would normally generate. OK, so what about changing wireguard to use TCP and TLS on port 443? It's still going to look very anomolous compared to a "normal" web exchange. Conceivably it might be mistaken for a websockets-based chat application or XMPP; but any adversary who wants to block wireguard is presumably going to want to block encrypted chat too. In summary: I think wireguard is a tool for connecting together island networks, over an untrusted but cooperative intermediate network. I don't think it should turn into a tool for steganography or policy busting. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Let's talk about obfuscation again 2018-09-06 15:24 ` Brian Candler @ 2018-09-06 21:16 ` James Cloos 0 siblings, 0 replies; 9+ messages in thread From: James Cloos @ 2018-09-06 21:16 UTC (permalink / raw) To: wireguard; +Cc: Brian Candler >>>>> "BC" == Brian Candler <b.candler@pobox.com> writes: BC> OK, so what about changing wireguard to use TCP and TLS on port 443? Using udp/443 for one end could allow making it look like quic. You'd need non-wg traffic on the port to reply like a quic server would. -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2018-09-07 8:49 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-09-06 0:06 Let's talk about obfuscation again StarBrilliant
2018-09-06 8:43 ` Dennis Jackson
2018-09-06 14:45 ` George Walker
2018-09-06 15:19 ` Fredrik Strömberg
2018-09-07 8:49 ` StarBrilliant
2018-09-06 15:34 ` Dennis Jackson
2018-09-06 16:10 ` Jason A. Donenfeld
[not found] <mailman.1542.1536245115.2201.wireguard@lists.zx2c4.com>
2018-09-06 15:24 ` Brian Candler
2018-09-06 21:16 ` James Cloos
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).