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.
We 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].
I 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?
Right 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.
In #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.
I’ve seen an IDS decide to classify all traffic, including management traffic as hostile. The result was an outage for one of the larger web shops in germany.
An IDS basing its fundamental action (detection) partly on ML can definitely be a good, valuable idea. An IPS basing its fundamental action (blocking traffic) partly on ML is the problem.
Well, it is said that the only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards.
Blanket denying all traffic is a good first step to ensuring that the system is really, really secure :P
It’s doesn’t really make any difference does it? The path isn’t used to indicate an IP packet flow, the “CONNECT-IP” method is what indicates the you want to send an IP packet flow to the server.
You could use the path to indicate different VPN endpoints, but ultimately the path isn’t needed at all.
Additionally all of this is gonna be inside a TLS session, so no external viewer will ever see any of the headers, including the path.
TL;DR the RFC doesn’t make this VPN endpoint a traditional http resource at all. It a special new HTTP method (like GET or POST) that indicates the client wants the server to treat the following data as an IP stream.
FWIW, I do get that it is its own method and I understand the intent of the specification (and thereby why it "wouldn't matter" in that worldview), but it feels weirdly non-HTTP for this functionality to not be treated as a resource... but like, I guess "fair enough" in that (looking at it again) the existing old-school proxy CONNECT method also has this flaw :/. I just feel like people should be able to easily "mount" functionality onto their website into a folder, and by and large most HTTP methods support this, with the ability to then take that sub folder and internal-proxy it to some separate backend origin server (as like, I would want to take the flows for anything under /secret/folder/--whether GET or PUT or PROPPATCH or CONNECT-IP--and have my front-end http terminator be able to transparently proxy them, without having to understand the semantics of the method; it could very well be that I am just living in a dream of trying way too hard to be fully-regular in a world dominated by protocols that prefer to define arbitrary per-feature semantics ;P).
I guess I am also very curious why you aren't defining this over WebTransport (which would allow it to be usable from websites--verified by systems like IPFS--to build e2e-encrypted raw socket-like applications, as I imagine CONNECT-IP won't be something web pages will be able to use). (For anyone who reads this and finds this thought process "cool", talk to me about Orchid some time, where I do e2e multi-hop VPN over WebRTC ;P.)
The Great Firewall does probing for ages now. It pauses the connection and sends its own request, checking what kind of protocol the server returns. Nothing stops these firewalls from trying ‘connect-ip’. The path could be used as a secret ‘key’ to thwart too-curious firewalls (though the protocol probably won't do much against DPI anyway).
It would then be weirdly important that a mis-authenticated CONNECT-IP then look the same as if CONNECT-IP were not implemented, as opposed to returning an authorization error of some kind (which seems weirder than hiding the method via the path).
True. But the path method has issues too, like, how would you implement that with HTTP 1.1? The "path" field is actually part of the target, so you would have to send the request like `CONNECT-IP https://remote-server/mount-point` which seems backwards. (EDIT: and also you still need to make sure you don't give the wrong kind of error if the path is wrong, like a 404 instead of a 501 not implemented or whatever)
As a possible solution for the discovery by authorization error problem, maybe a convention could be established where an authorization error is returned by default if CONNECT-* isn't configured.
Huh. It is possible that I simply didn't understand the spec, as I was (and am...) pretty sure that CONNECT-IP (at least at the HTTP semantics level) just takes a path (and only /)--like GET--without an associated "extra" authority, as it is creating an IP tunnel: there is no remote host (as there would be with an old-school CONNECT); like, what is the "target" here? I am just talking to the server and asking it to give me an IP bridge, right? What does "remote-server" represent to an IP tunnel?
I guess authentication via https before ‘connect-ip’ would work. Or, authenticating with headers in the same first ‘connect-ip’ request, if the server responds with ‘invalid method’ when not authenticated.
By the way, probing at connection time, that I mentioned in my original comment, isn't actually necessary. The GFW will just scan known popular-ish hosts, trying ‘connect-ip’ and banning everything that works as a proxy. (Connection-time probing would just make it easier to discover the hosts, such that collecting the IPs and stats separately is not needed.)
Many 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.
Typical 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).
Actually 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).
I've been using ip over TCP for years when that was the only thing allowed.
For the most part it'll work no problem. Yeah tunnelling IP over UDP would be better, but ip over TCP is the only think you have... It's gonna work, as long as the underlying connection is stable enough.
In 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.
The 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.
Hello, 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?
> 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.
TCP 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.
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.
If 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.
But 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.
Quic 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.
I 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.
You 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.
Any 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.
How 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"
It'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.
Many 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.
They 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.
QUIC is purpose-built to circumvent middleboxes. Enterprise networking benefits greatly from providing security and accountability via such middleboxes. The effort required to properly secure a network trying to circumvent your network security is costly and more complex.
Depends on the company, obviously. I don't care if employees do whatever on work computers, I care about protecting my network and my users.
In practice, all of this attempt to bypass middleboxes does not help my users browse securely. It makes it harder to block ads, it makes it harder to detect phishing sites and other threats, and that's about it.
I mean, that's a trend that's been ongoing in both the HTTP and TLS world for a while now, independent of QUIC. Similar complaints arose with the announcement of HTTP/2 being TLS only, if I recall, and TLS 1.3 would probably already be widely deployed right now if not for some complications with deployed middleboxes causing connection failures in the wild (which I don't entirely blame on them; after all, bugs happen...)
If you simply obey the standard, everything works perfectly well. For example, the only standard way to build HTTPS middleboxes is to fasten a standards compliant client and server together, when a corporate user tries to visit google.com the server presents them with its Certificate for google.com from your corporate CA, and the client connects to the real google.com, now the flow is naturally plaintext inside your middlebox and you can do whatever you want.
If you did that, when TLS 1.3 comes along, your middlebox client connects to google.com, the client says it only knows TLS 1.2, google.com are OK with that, everything works fine. When the corporate user runs Chrome, they connect to the middlebox server, it says it only knows TLS 1.2, that's fine with Chrome, everything works fine. The middlebox continues to work exactly as before, unchanged.
So what happened in the real world? Well of course it's cheaper to just sidestep the standards. Sure, doing so means you fatally compromise security, but who cares? So you don't actually have a separate client and server wired together, you wire pieces of the two connections together so that you can scrimp on hardware overhead and reduce your BOM while still charging full price for the product.
The nice shiny Chrome says "Hi, google.com I'm just continuing that earlier connection with a TLS 1.2 conversation we had, you remember, also I know about Fly Casual This is Really TLS 1.3 and here are some random numbers I am mentioning"
The middlebox pretends to be hip to teen slang, sure, pass this along and we'll pretend we know what "Fly Casual This Is Really TLS 1.3" means, maybe we can ask another parent later and it sends that to the real google.com
Google.com says "Hi there, I remember your previous connection wink wink and I know Fly Casual This Is Really TLS 1.3 too" and then everything goes dark, because it's encrypted.
The middlebox figures, well, I guess this was a previous connection. I must definitely have decided previously whether connecting to Google was OK, so no need to worry about the fact it mysteriously went dark before I could make a decision and it takes itself out of the loop.
Or worse, the middlebox now tries to join in on both conversations, even though it passed along these "Fly Casual This Is Really TLS 1.3" messages yet it doesn't actually know TLS 1.3, so nothing works.
A 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).
While 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.
Yep 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.
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.
You 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
Tunneling 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.
Running 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.
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 :)