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.
I have recently improved my rural multi-LTE setup by means of OpenMPTCPRouter [1]. MPTCP does a really great job at aggregating multiple paths for better throughput and reliability. Problem is, QUIC can’t do this, and while multipath QUIC exists [2], right now it’s more of a research project.
I’m afraid I’ll have to block UDP/443 at some point to prevent browsers from downgrading to 1/3 of available throughput...
Why would HTTP/3 not work with OpenMPTCPRouter? Looking at the documentation OpenMPTCRouter makes itself the gateway for you network, so all traffic TCP or UDP will get routed to, and over its multipath network, so UDP packets will be encapsulated in TCP, if your using a TCP based multipath layer.
Then on your VPC the UDP packets will be un-encapsulated and sent on as normal.
There are several possibilities of dealing with UDP traffic in OMR.
1) Multipath VPN (glorytun).
Thing is that UDP spread over multiple paths will not as well as MPTCP. MPTCP creates multiple subflows, one for each available path. Each subflow behaves (roughly) as a separate TCP connection, carrying some part of the traffic that goes through the pipe (byte-level splitting of the traffic, not packet-level). What's important here is that each subflow has its own separate congestion control.
The congestion control mechanism [1] is a very important aspect of TCP that basically controls its speed in a way that your internet connection is not overloaded and concurrent connections aren't disrupted. QUIC also includes a congestion control mechanism. But with MPTCP, each path is treated individually; with QUIC-over-multipath-VPN, where we just spread UDP packets somehow over multiple paths, the congestion control mechanism will get confused, b/c in the reality the congestion can happen separately on each path which will be hard to see; also, there will be packet reordering which will not improve the situation either. Basically, this is what happens when you try to spread plain TCP over multiple paths naively, and it's the reason why MPTCP was invented in the first place.
2) UDP-over-TCP.
In this case, I'm afraid that given that QUIC has its own congestion control, we might get unpleasant side effects similar to "TCP meltdown" as in case of TCP-over-TCP [2]
I spent the good part of last night compiling a previous version of nodejs to try out quic. I wanted to see if it could replace webrtc for a multiplayer game.
You have to compile a previous commit from the repo because the experimental implementation of quic was removed according to this issue: https://github.com/nodejs/node/pull/37067
Not sure when we can expect it to come back. You can just feel the pain in those comments. All that hard work.
Should be back soon - issue was related to the underlying openssl dependency, which is currently being updated in the newest Node release. I'd expect to see quic back within 2 to 3 months at most.
Are the QUIC HTTP/3 Connection Migration IDs an end run around limitations with cookies, ad blockers, MAC spoofing, and other forms of anti-tracking measures? My understanding is that these IDs survive network switching, sessions, etc.
QUIC connection IDs are transport level IDs, and are valid for as long as the connection is established. They will survive network path switches (by design to enable migration), but e.g. are not related any sessions on application level.
QUIC connection IDs can also change while the connection is active, so there no 1:1 relation between connection ID and connection either.
I use HTTP/3 since a few releases ago. I had to set the "network.http.http3.enabled" to "True". No issue so far (tested on a high-quality FTTH home connection and low-quality coax) with Google's website (including YouTube) and some websites under Cloudflare HTTP/3-ready CDN.
I use my own fork of the "http-and-ip-indicator" extension to know when HTTP/3 is in use[1]. It shows an orange bolt when HTTP/3 is in use for the top-level document.
I'd be interested in knowing how QUIC deals with networks where an upstream link has a lower MTU than the LAN, and some intermediate routers are blocking ICMP.
With TCP, the router would be set up to clamp TCP MSS, but how's this going to work with a UDP-based transport?
Both peers will start with a minimum MTU that is deemed to be safe (around 1200 bytes) and will independently start a path MTU discovery workflow from there. That allows each side to increase the MTU without having a dependency on the other end. For path MTU discovery, peers can send PING frames in higher MTU datagrams and detect their loss (miss of their acknowledgement)
Unrelated but a ton of work is being put into HTTP/3 while ESNI has been lingering in draft spec for years. As far as protocol work, I think their priorities are wrong.
Most wireless protocols hide packet loss from upper layers anyways using retry/FEC. I can't think of a common situation where wireless packet loss is even visible to layer 4, so efforts to build tolerance to it are usually pointless
Sure, but would the people working on http/3 be otherwise working on ESNI? Its a different problem space requiring different skills.
> Most wireless protocols hide packet loss from upper layers anyways using retry/FEC. I can't think of a common situation where wireless packet loss is even visible to layer 4, so efforts to build tolerance to it are usually pointless
Its attempting to build tolerance to sudden transient latency spikes interacting badly with congestion control algorithms. You can hide packet loss, you can't hide some random packet taking a lot longer to be delivered due to having to be retried.
> Its attempting to build tolerance to sudden transient latency spikes interacting badly with congestion control algorithms. You can hide packet loss, you can't hide some random packet taking a lot longer to be delivered due to having to be retried.
Good point. By using UDP you can get around head-of-line blocking. I didn't consider that
I think HTTP/2 and HTTP/3 are unnecessarily complex and offer little benefit for most web users and websites.
We need our technology to be secure against criminals and spies. To accomplish that, we must reduce complexity. Moving from HTTP/1.1 to HTTP/3 adds a lot of complexity:
- TCP -> UDP. Applications, proxies, and servers must implement complicated request stream processing logic. In TCP, this is handled by the OS kernel. The switch to UDP will bring many exploits and privacy leaks due to the huge amount of new code written for stream processing. Application performance will likely go down due to bugs and misconfiguration.
- Text -> Protocol Buffers. Protocol buffer parsing requires a large amount of new code. Applications & servers must either increase the complexity of their build systems by adding code generation or increase the complexity of their codebase by adding hand-coded parsing and serde (serializing & deserializing). There are plenty of ways to achieve the precision of protobufs with text-based protocols. Even JSON would be better. Debugging protobuf-based applications is difficult, increasing the costs of deploying applications. These costs disproportionately affect startups and small organizations.
- Uniplex -> Multiplex. With HTTP/1.1, application servers are straightforward to code: read a request from the stream, process it, and write a response. With multi-plexing, servers must handle concurrent requests over a single stream. This is an order of magnitude increase in complexity. It affects all aspects of the server. There will be many exploits and privacy leaks due to bugs in this new concurrent request processing code. Many production systems are more difficult to implement for multiplex protocols: firewalls, monitoring, bandwidth controls, DoS mitigation, and logging. For Google, these are not new costs since they already use Stubby (gRPC) internally for everything. But for the rest of the world, especially startups and small organizations, the switch to multiplex adds huge development and operational complexity for negligible benefit.
I think we need a better text-based HTTP protocol. HTTP group is solving Google's problems. We need it to solve our problems. Here's what we should do:
- Remove the unused features from HTTP/1.1. For example, multi-line headers.
- Eliminate ambiguity (and several classes of exploits):
- Make header names case-sensitive. Define all well-known headers with lower-case names.
- Forbid duplicate headers.
- Forbid leading zeros and sign indicators on numeric fields.
- Allow only lowercase hexadecimal.
- Require content-type header and forbid user-agents from inferring content-type.
- Make parsing simpler:
- Make standard header values mandatory and move them to the request/status line: content-length, content-encoding, content-type, transfer-encoding, and server name.
- Put the target path on its own line, encoded in UTF-8. Remove percent-encoding.
- Separate header names and values with a character that cannot occur in header names or values, like '\t'.
- Use UTF-8 for header values.
- Specify maximum sizes for request/response (sans body), request/status line, method name, content-type, server name, content-length field, target path, header key, header value, total header length, and number of headers.
- Use only one transfer encoding: chunked.
- Require content-length. Do not support uploads or responses of indeterminate length.
- Represent numeric values (content-length, chunk-length) using one format, either decimal or hex.
- Allow clients to detect tampering and corruption:
- Replace 'etag' header with a 'digest-sha-256' header.
- Add 'checksum-xxhash' and 'checksum-xxhash' headers for bodies and chunks. Pick an excellent hash function like xxHash.
- Allow browsers to control authentication:
- All connections are anonymous by default
- Forbid the "cookie" header. Replace it with a single-valued auth token that is part of the request line. Or even better, use the client authentication protocol described below. Browsers can now add a "log out" button which switches back to anonymous mode.
- Servers can request authentication (401).
- Support password-less challenge & response. This prevents phishing. It supports hardware tokens.
- Add a way for browsers to enroll a new "identity" with the server. This could be stored on a hardware token or just software. The browser creates a new identity for each website the user logs into. When the user wants to log in to a site for the first time, they click the "Login" button next to the URL bar. The browser re-requests the page with the enrollment header. The server can either accept the new identity (2xx) or show a form asking for a security code. The server returns the form with a 4xx status so it can get the enrollment headers again. The "Logout" button appears next to the Login button. It switches back to anonymous mode for that site.
- Remove HTTP Basic authentication (cleartext password).
- Remove HTTP Digest authentication (passwords).
- Replace TLS. It is mind-numbingly complex. Because of that, there are only a handful of implementations and most are buggy. TLS leaks private data. Replace it with three new protocols:
- An unauthenticated privacy protocol. This does not protect against MITM. Signs every data block with session key.
- Server authentication protocol. Client requests certificate by name. Server sends its certificate and signature of client-generated nonce. Every sent data block gets signed. Server sends another message with its certificate and signature of the privacy protocol session key and a nonce. Corporate MITM firewalls replace this message with their own certificate, which clients are configured to accept.
- Client authentication protocol. Every sent data block gets signed. A browser can generate a new identity with a new key pair and send the public key to the server in the 'enroll-rsa-2048' header. The server generates a certificate for the public key and returns it to the browser in the 'certificate' header. The browser uses this certificate in the client authn protocol.
- Do not support resuming sessions.
- All three protocols get a new version every 3 months with updated lists of supported algorithms, parameters, and features. No "extension" data fields. Public internet hosts must support only the eight latest versions. This means that unmaintained software will stop working after 2 years. This will prevent many data thefts, ransomware attacks, malicious hacks, and Internet worms.
- Encode certificates with human-readable JSON instead of ASN.1 DER. JER is not human-readable since it encodes DNS names in Base64. The ASN.1 format specification and DER encoding are unnecessarily complex.
- Provide test servers and clients that exercise all of the edge cases of the algorithms and try known attacks.
That's a long post, and I will not comment on all of it. However some very short thoughts:
HTTP/3 has nothing to do with protocol buffers. Yes, it uses a binary encoding for request headers on top of QUIC streams. And those QUIC streams use another binary encoding to get QUIC frame data into UDP datagrams. But neither of those are using protocol buffers. If a user uses HTTP/3 in the end (most likely through a library), they can store anything in the request response bodies - whether its binary data or just text data.
Multiplexing and binary encoding already exist in a HTTP/1.1 stack. The main difference is that it happens on the kernel level (it multiplexes IP datagrams in the end, and associates them with sockets). The main difference with QUIC is that this multiplexing layer now lives in application space. But since most users are not going to write their own library, they will rely on someone else to get that layer right. Either they want to have a solid kernel plus a solid TLS library on top, or they want a solid QUIC library. There is obviously a risk related to introducing anything new into a system, but once things mature it's not that different anymore.
Once users have a QUIC library, APIs don't really have to be harder than for handling HTTP/1.1 requests. One can easily offer blocking send() and receive() APIs to interact with request bodies, the encoding and multiplexing doesn't have to leak into application code.
I don't know why I thought it was protocol buffers. I see now that it's a TLV protocol. I think that is worse, since it requires custom binary parsers.
> Multiplexing and binary encoding already exist in a HTTP/1.1 stack.
This is disingenuous. The majority of code supporting HTTP/1.1 is in text processing. Binary encoding only happens while transfer encoding bodies. TCP is multiplexed over IP, but very few engineers ever think about that because our tools deal with TCP connections.
I need to understand the technology my systems depend on so I can solve problems. I accept complexity when it is necessary or when it brings strong benefits.
Things that are necessary complexity: JPEG libraries, database engines, Rust's borrowing rules, and TLS (only because no straightforward alternative exists).
You don't need to understand every implementation detail of a technology to solve problems, you need to understand the abstraction it exposes. In this case HTTP/2 and HTTP/3 expose the same abstraction that HTTP/1.1 exposes.
The only thing you need to know is that the cost each request/response is much smaller then before, so you can make more of them with less overhead. That's it.
Without abstraction this world is so complex, we wouldn't be able to get out of bed in the morning and put our pants on.
I agree with the massive increase in complexity brought on by newer versions of HTTP and the attempt at essentially reimplementing TCP over UDP, but I think a binary protocol will be much simpler and more efficient than a text one.
Eliminate ambiguity (and several classes of exploits):
It's easier to "start small" (i.e. with a short binary encoding) that won't be much ambiguous in the first place, than to try to add restrictions (and thus additional complexity) to a freeform text protocol. Or put another way, instead of adding error cases, it's better when there are no error cases in the first place.
Encode certificates with human-readable JSON instead of ASN.1 DER.
Hell no. DER is prefix length-delimited, JSON (and text in general) is not.
This means that unmaintained software will stop working after 2 years.
Hell fucking no! The last thing that anyone who cares about things working wants is planned obolescence and even more constant churn (which just leads to more and more bugs.) If anything, that will only make the "handful of implementations" of TLS turn into perhaps one (i.e. Google's), or maybe two at most. Thats even worse.
Replace TLS. It is mind-numbingly complex.
Replace it with what? Your proposal essentially reinvents the main pieces of TLS (authentication, confidentiality), and TLS is already quite modular with respect to that.
Have you tried to write an X.509 DER PEM file parser? I started one. Just reading the specs (X.509, ASN.1, DER, & PEM) takes two days. If writing a JSON parser is a walk down the block, then writing an X.509 cert parser is a marathon.
How is TLS modular? It mixes encrypted and unencrypted message types [0], leading to implementation vulnerabilities [1]. It contains many unused and unnecessary features and extensions, some of which are very bad ideas (renegotiation, client_certificate_url). We all deserve a good protocol to protect our data and systems. The complexity of TLS helps the incumbents, stifles innovation, and harms privacy and security.
Many organizations spend a lot of money and effort to upgrade software and prevent obsolete software from running. This will become a bigger need in the future as ransomware attacks become more common. Building mandatory upgrades into an Internet protocol would take boldness and courage. The benefits will accrue to everyone in society: Less of our data will get stolen by criminals and spies. Fewer organizations will get extorted by criminals. Fewer hospitals will get shut down.
PEM is not DER, it's base64'd DER, and not necessary to implement TLS (which only uses DER for X509.) I haven't written any code for it, but I've debugged some, and read the spec and hexdumps, and I'd much rather work with DER than JSON. Everything length-prefixed, no "keep reading until you find the end" horrors. JSON is simple on the surface, complex on the inside; ASN.1 is somewhat like the opposite of that. You may find this article enlightening: https://news.ycombinator.com/item?id=20724672
The complexity of TLS helps the incumbents, stifles innovation, and harms privacy and security.
...and your "solution" to replace it with something that churns even more insanely frequently won't "helps the incumbents"? We already have the horrible Chrome/ium monopoly situation as evidence. I've just about had it with the fucking "innovation", I want stability.
The benefits will accrue to everyone in society: Less of our data will get stolen by criminals and spies. Fewer organizations will get extorted by criminals. Fewer hospitals will get shut down.
Every utopian vision turns into a dystopia. That "think of the security!" doublespeak grandstanding is becoming disturbingly Google-ish.
I'm done here --- clearly you can't be convinced (or are deliberately trolling), and neither can I.
I did not intend for you to become frustrated. I am being earnest.
Most software systems change only by adding complexity and features. This is because owners rarely have the courage to break any users' stuff. This is OK for a growing company since they earn more money as they add complexity. But it's counter-productive for security. Security depends on simplicity.
Evolving systems means adding support for new things. To evolve systems and maintain simplicity, we must also remove support for old things.
Dropping support for a feature is currently a political ordeal. Folks maintaining old systems don't want to upgrade them to use the new thing. So they push back against the drop. Regular dropping will force these organizations to adopt regular upgrade processes. With regular dropping, protocol/library/language maintainers can drop features without incurring much extra work for users. This will let them get rid of technical debt and iterate much faster, increasing the rate of innovation.
> Have you tried to write an X.509 DER PEM file parser? I started one. Just reading the specs (X.509, ASN.1, DER, & PEM) takes two days. If writing a JSON parser is a walk down the block, then writing an X.509 cert parser is a marathon.
I have. It wasn't particularly difficult. Yes the specs took about two days to get my head around but that's not a large amount of time. I certainly wouldn't describe it as a marathon.
> Hell no. DER is prefix length-delimited, JSON (and text in general) is not.
This is a bit disingenuous, Content-Length header is required, or defacto required, and every http 1.1 server out there has a reasonable maximum allowed request header size.
Do you mean libraries for backend languages, like Go
and Java, or servers, like Nginx and Caddy? Because for Go
there is the quic-go module[1], and since Caddy is written
in Go, it already has (experimental) support for HTTP/3[2].
Envoy proxy has initial support using Google's Quiche. Docs and example configs are being worked on. I wrote up some h3 client and Envoy proxy testing this week [0].
Depending on what you want to accomplish, an option is running your services in a cloud that supports terminating QUIC on their front-end load balancers. Google Cloud does, for example.
I wish this trend to start articles with 'tl;dr' would stop. Opening with a summary paragraph predates the attention-deficit/time-starved age by many years, and is not an innovation.
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 :)