* WireGuard protocol blocking in China, swgp-go (userspace obfuscation proxy)
@ 2022-06-09 22:05 David Fifield
2022-06-14 13:13 ` Nico Schottelius
2022-06-14 14:15 ` Alex
0 siblings, 2 replies; 4+ messages in thread
From: David Fifield @ 2022-06-09 22:05 UTC (permalink / raw)
To: wireguard
I am forwarding some information about WireGuard blocking and
anti-blocking that was posted to a censorship circumvention forum.
swgp-go is a userspace obfuscation proxy that aims to hide WireGuard's
distinctive protocol fingerprint (message_type and reserved_zero fields,
fixed packet lengths). It super-encrypts part or all of WireGuard
packets using a preshared symmetric key, and optionally adds padding.
The security of the channel relies on the encryption and authentication
of the underlying WireGuard tunnel, which requires less overhead than a
general-purpose circumvention proxy would.
https://github.com/database64128/swgp-go
https://github.com/net4people/bbs/issues/117
There is a past discussion on this mailing list of something similar.
That one was in the kernel; this one is in userspace.
https://lists.zx2c4.com/pipermail/wireguard/2021-September/007142.html
https://github.com/net4people/bbs/issues/88
Separately, the swgp-go announcement post comments on the dynamics of
WireGuard blocking in China:
> The GFW will block the remote peer's UDP port for a few days after
> about a week's continuous usage.
> ...
> ... the GFW only started blocking WireGuard on IPv4 this February.
GFW = Great Firewall, the collective name for various censorship systems
used by the government of China. The pattern of "detect, then block for
a limited time, then unblock" is typical for the GFW, though the time
intervals are usually rather shorter. For example, when the GFW began to
block the use of the ESNI extension in TLS 1.3, it would block the
server endpoint for 120 or 180 seconds:
https://gfw.report/blog/gfw_esni_blocking/en/#residual-censorship
I have not confirmed the reported blocking behavior in China. It's worth
keeping in mind also that blocking in China can differ across networks
and geographic regions. I did find a Reddit post from 3 months ago, from
the Fuzhou region, saying that WireGuard is detected and blocked within
24 hours:
https://www.reddit.com/r/WireGuard/comments/t0bpy3/wireguard_detected_and_blocked_by_gfw/
A past message on this mailing list about temporary problems with the
WireGuard protocol in Russia last year:
https://lists.zx2c4.com/pipermail/wireguard/2021-September/007050.html
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: WireGuard protocol blocking in China, swgp-go (userspace obfuscation proxy) 2022-06-09 22:05 WireGuard protocol blocking in China, swgp-go (userspace obfuscation proxy) David Fifield @ 2022-06-14 13:13 ` Nico Schottelius 2022-07-02 23:21 ` David Fifield 2022-06-14 14:15 ` Alex 1 sibling, 1 reply; 4+ messages in thread From: Nico Schottelius @ 2022-06-14 13:13 UTC (permalink / raw) To: David Fifield; +Cc: wireguard David Fifield <david@bamsoftware.com> writes: > I am forwarding some information about WireGuard blocking and > anti-blocking that was posted to a censorship circumvention forum. In regards to this topic I was wondering if it makes sense to have a more generic obfuscation proxy that can carry tcp/udp payload? Maybe this already exists, but I would think that something that hops protocols (IPv6, IPv4 endpoints, tcp/udp encapsolution), changes ports and uses envelope based tunneling (http, https, smtp, imap - worst case DNS) would make it easier to sustain communication even in more serious filtering scenarios. Given such a "generic obfuscator", it could be combined with "protocol" modes, i.e. enhancing protocols such as wireguard with the presented algorithm, making it even harder to predict the content. I'd assume some performance regressions using such an obfuscator, but maybe it could even "learn" the proper obfuscation by detecting blocks on easier to detect obfuscation and then switching to a stronger, but less efficient obfuscation. Wondering what your thoughts are on this. Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: WireGuard protocol blocking in China, swgp-go (userspace obfuscation proxy) 2022-06-14 13:13 ` Nico Schottelius @ 2022-07-02 23:21 ` David Fifield 0 siblings, 0 replies; 4+ messages in thread From: David Fifield @ 2022-07-02 23:21 UTC (permalink / raw) To: wireguard On Tue, Jun 14, 2022 at 03:13:11PM +0200, Nico Schottelius wrote: > > I am forwarding some information about WireGuard blocking and > > anti-blocking that was posted to a censorship circumvention forum. > > In regards to this topic I was wondering if it makes sense to have a > more generic obfuscation proxy that can carry tcp/udp payload? > > Maybe this already exists, but I would think that something that hops > protocols (IPv6, IPv4 endpoints, tcp/udp encapsolution), changes ports > and uses envelope based tunneling (http, https, smtp, imap - worst case > DNS) would make it easier to sustain communication even in more serious > filtering scenarios. > > Given such a "generic obfuscator", it could be combined with "protocol" > modes, i.e. enhancing protocols such as wireguard with the presented > algorithm, making it even harder to predict the content. > > I'd assume some performance regressions using such an obfuscator, but > maybe it could even "learn" the proper obfuscation by detecting blocks > on easier to detect obfuscation and then switching to a stronger, but > less efficient obfuscation. There are many designs for anti-censorship protocol obfuscation proxies, including multi-modal ones like you suggest, more or less fanciful, more or less realized. You can get a list of some of the more popular and practical ones under the "censorship-circumvention" topic on GitHub: https://github.com/topics/censorship-circumvention There's plenty of research on the topic as well, sometimes leading to practical systems. CensorBib has the most important papers: https://censorbib.nymity.ch/ For an introduction and survey of ideas that have been proposed, I recommend reading "Making Sense of Censorship Resistance Systems" ( https://censorbib.nymity.ch/#Khattak2016a ) and "Towards Grounding Censorship Circumvention in Empiricism" ( https://censorbib.nymity.ch/#Tschantz2016a ). There are summaries of recent research papers on censorship at https://github.com/net4people/bbs/issues?q=label%3A%22reading+group%22 . The idea of pluggable obfuscation modules is fairly ubiquitous, and has been systematized in various ways: https://www.pluggabletransports.info/ https://shadowsocks.org/guide/sip003.html https://guide.v2fly.org/en_US/advanced/advanced.html Let me suggest, however, that it is a mistake to focus too narrowly on protocol obfuscation. It is a necessary element, but not the most important one nor the one that's hardest to get right. There's no shortage of obfuscators, and even naive protocol obfuscation usually works even against well-resourced censors like the GFW. The weak link of circumvention systems tends not to be what cover protocols they use, but the particulars of their connection establishment. (This point is made in the two SoK papers I linked above.) Empirically, censors prefer to disrupt communications during the early stages, when the connection is being first set up. It is faster, cheaper, and overall more effective than long-term steady-state protocol processing. Take HTTP for example. It's not hard to obfsucate a network tunnel so that it resembles HTTP at some degree of fidelity. One might think that to in order to block such a tunnel, a censor needs to somehow distinguish tunnel HTTP from "real" HTTP. But most real-world censors will never go that far: instead they will look at the destination IP address or Host header of HTTP requests, or send their own probes to suspected servers to see how they respond; but in any case they'll add the server's IP address to a firewall block list, and call it a day. The hard part of obfuscating a tunnel as HTTP is not faithfully implementing HTTP; it's protecting the server's address from being blocked for reasons unrelated to HTTP. Protocol obfuscation cannot help when it is not the protocol that is being attacked. Having the tunnel hop across different endpoints is not a bad idea, but consider: how does a legitimate user learn what endpoints to use, without a censor learning them also? There are ways to protect circumvention endpoints, from single-user servers (which I believe is the model swgp-go intends), to strategic distribution of endpoint addresses, to colocating proxy servers with other network services, but these go beyond the realm of protocol obfuscation. What I like about swgp-go is that it has a narrowly targeted goal (to hide the most salient distinguishers of WireGuard, with low overhead) and it is designed for a realistic and informed threat model. The protocol obfuscation is re-encryption and padding, but it doesn't have to be more than that. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: WireGuard protocol blocking in China, swgp-go (userspace obfuscation proxy) 2022-06-09 22:05 WireGuard protocol blocking in China, swgp-go (userspace obfuscation proxy) David Fifield 2022-06-14 13:13 ` Nico Schottelius @ 2022-06-14 14:15 ` Alex 1 sibling, 0 replies; 4+ messages in thread From: Alex @ 2022-06-14 14:15 UTC (permalink / raw) To: David Fifield; +Cc: wireguard [-- Attachment #1: Type: text/plain, Size: 358 bytes --] On Thu, 9 Jun 2022 16:05:22 -0600 David Fifield <david@bamsoftware.com> wrote: > I am forwarding some information about WireGuard blocking and > anti-blocking that was posted to a censorship circumvention forum. > You may find this information[0] relevant and helpful. Regards, Alex [0] https://realworldcrypto.files.wordpress.com/2013/06/shrimpton.pdf [-- Attachment #2: shrimpton.pdf --] [-- Type: application/pdf, Size: 2486747 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-07-02 23:21 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-06-09 22:05 WireGuard protocol blocking in China, swgp-go (userspace obfuscation proxy) David Fifield 2022-06-14 13:13 ` Nico Schottelius 2022-07-02 23:21 ` David Fifield 2022-06-14 14:15 ` Alex
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).