12 ms·
Is anyone else hyped about the possibility of tunneling traffic over QUIC? Public networks in coffee shops and libraries that block outbound SSH and outbound W
by codetrotter 6y ago
Is anyone else hyped about the possibility of tunneling traffic over QUIC?
Public networks in coffee shops and libraries that block outbound SSH and outbound Wireguard are the bane of my existence when I am traveling and I try to get some god damn work done.
With HTTP/3 most public networks in coffee shops, libraries etc are eventually going to allow QUIC. This means UDP tunnels masquerading as QUIC traffic, as well as tunneling over QUIC itself, is probably going to work. Eventually.
I am cautiously optimistic :)
- legulere 6y agoOr they just continue blocking UDP and browsers fall back to http1/2
- CameronNemo 6y agoCan you not disguise the wireguard tunnels as something else? E.g. just set the destination/listen port as 443/UDP? Or 53, 123.
- judge2020 6y agoWhile not usual for places like coffee shops, i've seen cruises and hotels do DPI since probably a sizable amount of revenue can be generated from fast wifi access or by unblocking all sites.
- CameronNemo 6y agoYep that is always an issue. Not sure how a hypothetical QUIC tunnel would avoid that, though. Would appreciate any info you can provide on mitigating deep packet inspection blocking techniques.
- grishka 6y agoI've been tempted to write a quick-and-dirty websocket tunnel for quite some time. Let's see how they DPI any of that without breaking anything else.
- shawnz 6y agoWhy not just use an HTTP CONNECT proxy running over HTTPS?
- grishka 6y agoYou could do that? Well, you probably could. But there are some "proactive" DPIs that make a request themselves before letting you through. Would this protect against that? It's easy to set up a regular web server that would serve what everyone would see as an ordinary personal website, except when you make a request to a secret URL.
- shawnz 6y agoYou could require authentication (and as other posters pointed out, make sure to spoof any wrong authentications for maximum deniability). It is also simple to serve some pages over HTTP alongside the proxy functionality so that the server appears to be a typical web server. Just turn on mod_proxy_connect in addition to your existing httpd configuration if you use Apache for example. I use this method on my domains, although I've never tried using it from within e.g. China
- mjsir911 6y agoWe're already most of the way there with SSTP, although it's a bit fiddly with SNI https://en.wikipedia.org/wiki/Secure_Socket_Tunneling_Protocol https://en.wikipedia.org/wiki/Secure_Socket_Tunneling_Protoc...
- codetrotter 6y agoTunneling over TCP has problems. (The article you linked mentions this as well.) This TCP meltdown problem is especially prominent in public WiFi networks where they often like to dramatically limit the bandwidth to the clients that connect to their network. So UDP tunneling will work much better there. That’s why I am excited about maybe finally having tunneling over UDP be a reality on public networks in coffee shops and libraries in the future thanks to HTTP/3 and QUIC where historically the mentioned kinds of networks have often been blocking basically all UDP traffic except DNS.
- aduitsis 6y agoHello, it's not like every venue will be hard pressed to accommodate QUIC quickly, right? Please consider that today, in 2021, IPv4 is still the only thing supported in many venues. It took almost 20 years for IPv6 to become universally supported by Operating Systems, ISPs, providers, etc, but still you have to have IPv4. And I dare say IPv6 was much much more critical to have than QUIC. But having said all that, what is there to allow in QUIC? Isn't it just using UDP?
- livre 6y ago> Hello, it's not like every venue will be hard pressed to accommodate QUIC quickly, right? If browsers fall back to regular HTTPS when the QUIC connection fails there won't be much incentive in making sure QUIC works or isn't blocked.
- lxgr 6y ago> Isn't it just using UDP? Yes, but there‘s still networks blocking everything but TCP 80/443.
- midasuni 6y agoIn which case quic won’t work. But your vpn over tcp/443 will be fine. Is udp/53 blocked too?
- Quekid5 6y ago> Hello, it's not like every venue will be hard pressed to accommodate QUIC quickly, right? Your aren't wrong about that, given the amount of fallback browsers do, but IPv6 actually required upgrading key pieces of hardware at critical points in the infrastructure[0]. Not sure if there's any hardware released in the last 10+ years that doesn't support it, but who knows? ... and yes, QUIC is "just UDP". [0] ... and dare I say: a more compelling immediate use case. At the time is was designed the address shortage wasn't actually looking all that dire. It might actually have been invented/designed too soon... like it solutions to Y2K had come out in 1980 or something.
- saurik 6y agoI already support VPN over WebRTC in Orchid, and intend to support WebTransport (though the premise of that protocol irks me a bit) to get unreliable packets over QUIC as these standards finish forming. https://github.com/OrchidTechnologies/orchid https://github.com/OrchidTechnologies/orchid
- the8472 6y agoTCP is far from optimal for tunneling multiple flows, but you can still tweak it a lot by using a recent(ish) linux kernel which will allow you to use FQ_CODEL + BBR + NOTSENT_LOWAT to reduce loss sensitivity and minimize the excess buffering in the presence of bulk flows over the tunnel. Well, and by not using SSH for tunneling, since that brings yet another layer of flow control. If you're on a fixed-bandwidth connection disabling SSR might help too. These are all sender-side changes, so you need to control the remote end of the VPN too.
- Siira 6y agoCan you point to some guide on exactly which bash commands to run for this?
- the8472 6y agoJust to repeat myself, these are sender-side modifications, so if you're the receiver and don't control the sender they won't do any good. https://blog.cloudflare.com/http-2-prioritization-with-nginx/ https://blog.cloudflare.com/http-2-prioritization-with-nginx... (you can replace fq with fq_codel on newer kernels) https://stackoverflow.com/questions/17015611/how-to-disable-tcp-slow-start-in-linux https://stackoverflow.com/questions/17015611/how-to-disable-... And for not using SSH for tunneling, well you could try openvpn for example which offers TCP- and UDP-based transports and if you're stuck with TCP then it merely nests TCP-in-TLS-in-TCP which is only 2 layers of flow control rather than TCP-in-SSH-in-TCP which is 3 layers of flow control. Note that this is not universal network tuning advise. It's meant for bursty or bulk traffic in TCP tunnels over wired connections with low packet loss.
- netflixandkill 6y agoBeen doing wireguard over udp 443 for a long time. Works pretty consistently. Probably take a few years for the low-effort network blocks to figure out how to deal with that.
- lxgr 6y agoInteresting, I wonder if this is because of low effort firewall rules (just mirror the TCP settings for UDP) or explicitly to allow QUIC.
- netflixandkill 6y agoQuic has been around long enough that I suspect it's simply a common policy for both tcp and udp on 443. If you just want to charge for access, rate limiting is easier and there is almost never any local person involved in managing it. A lot of VPN blocking isn't a specific, deliberate policy choice by the network owner, it comes in from default policy options on whatever awful vendor they use. The people seriously concerned about outgoing tunnels providing access back into protected networks that hides from normal packet inspection are a different case.
- adamfisk 6y agoWireguard traffic is easy to identify and therefore easy to block.
- bawolff 6y agoBut typically coffee shops aren't really putting much effort into blocking vpns, they're doing some silly block everything not 80 or 443. Its not like they're trying to bypass the great firewall of china.
- midasuni 6y agoIt’s possible that QUiC will mean in some places udp/443 will be blocked but other udp won’t be.
- api 6y agoWe've looked at QUIC transport for ZeroTier for this reason.
- cmeacham98 6y agoIn the meantime, consider trying udp2raw[1], which will allow you to fake UDP over TCP (by colluding on both sides of the tunnel) and works pretty well on coffee shop WiFi in my experience. 1: https://github.com/wangyu-/udp2raw-tunnel https://github.com/wangyu-/udp2raw-tunnel
- moonchild 6y agoSee also udptunnel, an older implementation of the same idea - http://www.cs.columbia.edu/~lennox/udptunnel/ http://www.cs.columbia.edu/~lennox/udptunnel/
- wangyu 6y agoThe idea is pretty different. This one is implemented by a regular tcp socket, udp2raw is implemented by raw socket. Raw socket based implementation bypasses congestion control/retransmission/head-of-line-blocking, thus has much better theoretical performance.
- moonchild 6y agoOh, really? Interesting, I had thought that udptunnel did as you suggest. Perhaps I was confusing it with something else.
- georgyo 6y agoMany people have answered your comment, but I don't think any of them actually addressed your comment... If a public access point has a restrictive network policy, then QUIC will change nothing. There is nothing that QUIC enables that people browsing the web will demand. A user cannot even tell if they are using QUIC (or http2) for that matter. The network operator is either non-technical and does not care about QUIC; or technical but trying to actively prevent people from using VPN and/or torrenting. There are many ways to VPN that look like tcp http. tcp over tcp is okay if the connection is stable.
- aidenn0 6y agoI think the idea is that TCP over QUIC will be better than TCP over TCP, particularly since public wifi can have highly variable latency.
- midasuni 6y agoSo your typical coffee shop has router capability to determine a quic tunnel over udp/443 vs a WireGuard tunnel over UDP/443?
- littlecranky67 6y agoTypical coffe-shop APs have disabled UDP all together, mostly because it is not needed for HTTP and "intended use" of a WiFi provided at a coffee shop. I would say they disable it deliberately to prevent VPN tunneling, its probably a sane decision to disable anything not needed for the intended purpose (or not putting effort in enabling it).
- wildfire 6y agoActually my typical coffee shop does not constrain UDP in any way; otherwise DNS would break. They are not sophisticated, they just do not want people leeching large amounts of data via the connection (which they basically perceive as http/1 or http/2). Anyone using "something else" is basically noise.
- achernya 6y agoWe have built a VPN over QUIC, and the core code is open source already [0]. We're working on standardizing "IP Proxying" over QUIC as part of the MASQUE working group at IETF. So far, we've adopted a requirements document [1] and have started work on an implementation [2]. [0] https://quiche.googlesource.com/quiche/+/refs/heads/master/quic/qbone/ https://quiche.googlesource.com/quiche/+/refs/heads/master/q... [1] https://tools.ietf.org/html/draft-ietf-masque-ip-proxy-reqs-01 https://tools.ietf.org/html/draft-ietf-masque-ip-proxy-reqs-... [2] https://tools.ietf.org/html/draft-cms-masque-connect-ip-00 https://tools.ietf.org/html/draft-cms-masque-connect-ip-00
- tankenmate 6y agoI can see a number of jurisdictions around the world either blocking and/or profiling this sort of traffic. Is any form of "chaffing" / plausible deniability built into the protocol?
- achernya 6y agoRight now we're focusing on building a functional core protocol and making sure it's sufficiently extensible. It should be possible to build chaffing as an add-on extension down the line.
- saurik 6y agoIn #2, why is the path hardcoded to /? One of the things I've considered somewhat important in my similar work (on Orchid, using HTTPS+WebRTC) is the ability to "embed" a VPN as a sub-resource on some existing website.
- therein 6y agoFun to imagine some application layer firewall somewhere go: "that /static/css/style.css sure is large and requiring a lot of two way communication".
- giovannibonetti 6y ago
- oliwarner 6y agoIf it's a bandwidth issue for them, isn't it more likely they'll just block UDP/443?
- jk7tarYZAQNpTQa 6y agoWhat stops you from tunneling VPN inside TLS, or directly over TCP? Something like https://github.com/moparisthebest/wireguard-proxy https://github.com/moparisthebest/wireguard-proxy
- pixl97 6y agoTCP over TCP vpn is a bad idea, udp is better.
- jk7tarYZAQNpTQa 6y agoIsn't ipsec just TCP over TCP? UDP might be better, but the TCP solution works today, no need to wait until HTTP/3 gets widely adopted.
- IcePic 6y agoNo, ipsec is its own protocol, so it would be most similar to "over UDP"
- GormanFletcher 6y agoA surprising number of limited-access networks only do port blocking, not protocol sniffing. This means many will cheerfully let you connect to an SSH server over port 443 (useful for a SOCKS proxy).
- partyboy 6y agoTake a look at my project? https://github.com/tobyxdd/hysteria/ https://github.com/tobyxdd/hysteria/
- ocdtrekkie 6y agoAny good enterprise environment will aggressively block QUIC. The benefits to end users (or network admins) isn't there, and the limitations upon network management are massive. Sure, your family-run coffee shop won't bother to block QUIC, but if Starbucks' IT is doing their job, they will.
- partyboy 6y agoHow is this going to work when a lot of sites/apps start to use QUIC? It's like blocking HTTPS because "the limitations upon network management are massive"
- sjwright 6y agoHTTPS is necessary. QUIC is not. It’s going to be a long time before any site requires QUIC in order to work.
- pimterry 6y agoMany sites will support QUIC soon, but they won't strictly require it for a long time, it's negotiated and backward compatibility isn't irrelevant quite yet.
- Matthias247 6y agoThey will always have to support a fallback (HTTP/1.1 or HTTP/2), because not all users are guaranteed to have success with QUIC. Blocked UDP traffic and ports can be some reasons why it won't work, too small supported MTUs can be other reasons.
- tialaramex 6y agoIt's going to make things work slightly less well from the corporate office than they do at home on your cheap setup. That's a continuing trend, and you might recognise it from other aspects of life. Paying more while deliberately choosing a worse service is pretty much life-as-usual for corporations. One of my previous employers had a deal to get train tickets. In my country train tickets for actual consumers, even ordered online, don't have a service fee. After all in choosing to order online you're actually saving them money, why would it cost extra? But the corporation paid about 5% fees to get train tickets from a company which also provides those zero fee services to individuals. Or think about all the companies where Windows XP desktops were still being used years after they were obviously the wrong choice. Monday to Friday the world IPv6 utilisation goes down, but every weekend it's back up. Because at home people have IPv6 (even if they've never thought about it) while at work somebody explicitly turned that off. One of the nice things about working from home is that my network works very well, whereas whether I worked for a startup or a billion dollar corporation it was always one problem or another when I was in the office. Which reminds me, I should really look for a new job as this pandemic begins to slacken off.
- crazygringo 6y agoYou can already tunnel traffic over HTTPS, and I've never been to a coffee shop or library that blocked that. Have you tried that when traveling? I used to do it frequently something like 15 years ago to use SSH, Remote Desktop, anything. (Back then it was a software package called "orenosp" that you set up on your client laptop and then a server of your choice, like your home computer -- not sure what tool is popular now.) On the other hand, public networks would only have to allow QUIC if regular HTTP(S) fallback ever stopped being supported by most webservers, which... who knows if that would ever happen.
- jlokier 6y agoIf you're already encountering blocks, I don't think you can assume there won't be blocks on QUIC unfortunately. Here are just a selection of vendors advice. There's plenty of them, and they are probably used by some schools, libraries etc. https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClarCAC https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?... > Our recommendations: > Palo Alto Networks recommends creating a security policy in the firewall to block the QUIC application. https://community.spiceworks.com/topic/2146987-do-you-block-quic https://community.spiceworks.com/topic/2146987-do-you-block-... > Do You Block QUIC > Thinking about it, ... > Yes, ... > Yes, ... > Yes, ... > No, ... https://www.fastvue.co/fastvue/blog/googles-quic-protocols-security-and-reporting-implications/ https://www.fastvue.co/fastvue/blog/googles-quic-protocols-s... > How Google’s QUIC Protocol Impacts Network Security and Reporting > ... inadvertently created a security hole for many organizations. > ... At the time of writing, the advice from most firewall vendors is to block QUIC until support is officially added to their products. https://help.zscaler.com/zia/managing-quic-protocol https://help.zscaler.com/zia/managing-quic-protocol > Managing the QUIC Protocol > Zscaler best practice is to block QUIC https://www3.trustwave.com/support/kb/print20269.aspx https://www3.trustwave.com/support/kb/print20269.aspx > Blocking web traffic over QUIC > The recommended fix is to block outbound UDP on ports 80 and 443 ...
- esaym 6y agoIt is not hard to set up openvpn in TCP mode and running on port 443 you know....
- kyriakos 6y agoWhy do they block ssh and wireguard? Can't think of a good reason
- xg15 6y agoWhat has stopped you from tunneling traffic over https (or more generally TLS on port 443) before?
- thayne 6y agoRunning a TLS based VPN (such as openvpn) on TCP port 443 will already look a lot like https. Although, it would probably be possible to guess it is a vpn from traffic patterns. The same8ght be trie of http/3 though.
- dgemm 6y agoShouldn't that sort of tunnel over TLS be possible now?
- kdmytro 6y agoWhy don't you simply put your sshd on port 443?
- Siira 6y agoYou can already use, e.g., trojan, to tunnel over HTTPS.