15 ms·
QUIC and HTTP/3 Support Now in Firefox Nightly and Beta
- codetrotter 5y agoIs 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 5y agoOr they just continue blocking UDP and browsers fall back to http1/2
- CameronNemo 5y 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 5y 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 5y 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 5y 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 5y agoWhy not just use an HTTP CONNECT proxy running over HTTPS?
- grishka 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y ago> Isn't it just using UDP? Yes, but there‘s still networks blocking everything but TCP 80/443.
- midasuni 5y agoIn which case quic won’t work. But your vpn over tcp/443 will be fine. Is udp/53 blocked too?
- Quekid5 5y 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 5y 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 5y 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 5y agoCan you point to some guide on exactly which bash commands to run for this?
- the8472 5y 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 5y 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 5y 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 5y 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 5y agoWireguard traffic is easy to identify and therefore easy to block.
- bawolff 5y 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 5y agoIt’s possible that QUiC will mean in some places udp/443 will be blocked but other udp won’t be.
- api 5y agoWe've looked at QUIC transport for ZeroTier for this reason.
- cmeacham98 5y 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 5y 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 5y 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 5y agoOh, really? Interesting, I had thought that udptunnel did as you suggest. Perhaps I was confusing it with something else.
- georgyo 5y 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 5y 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 5y agoSo your typical coffee shop has router capability to determine a quic tunnel over udp/443 vs a WireGuard tunnel over UDP/443?
- littlecranky67 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y 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 5y ago
- oliwarner 5y agoIf it's a bandwidth issue for them, isn't it more likely they'll just block UDP/443?
- jk7tarYZAQNpTQa 5y 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 5y agoTCP over TCP vpn is a bad idea, udp is better.
- jk7tarYZAQNpTQa 5y 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 5y agoNo, ipsec is its own protocol, so it would be most similar to "over UDP"
- GormanFletcher 5y 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 5y agoTake a look at my project? https://github.com/tobyxdd/hysteria/ https://github.com/tobyxdd/hysteria/
- ocdtrekkie 5y 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 5y 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 5y agoHTTPS is necessary. QUIC is not. It’s going to be a long time before any site requires QUIC in order to work.
- pimterry 5y 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 5y 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 5y 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 5y 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 5y 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 5y agoIt is not hard to set up openvpn in TCP mode and running on port 443 you know....
- kyriakos 5y agoWhy do they block ssh and wireguard? Can't think of a good reason
- xg15 5y agoWhat has stopped you from tunneling traffic over https (or more generally TLS on port 443) before?
- thayne 5y 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 5y agoShouldn't that sort of tunnel over TLS be possible now?
- kdmytro 5y agoWhy don't you simply put your sshd on port 443?
- Siira 5y agoYou can already use, e.g., trojan, to tunnel over HTTPS.
- crypt0x 5y agoDoes someone know if this includes the QuicTransport JS API? Im still salty that Google scrapped the p2p mode from chrome, which could have been a nice alternative for webrtc, too.
- chrissnell 5y agoWhat server-side options do we have for QUIC?
- dragonwriter 5y agoHere’s a list of implementations. There’s quite a few backend (either servers or server libraries.) https://github.com/quicwg/base-drafts/wiki/Implementations https://github.com/quicwg/base-drafts/wiki/Implementations
- ainar-g 5y agoDo 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]. [1]: https://github.com/lucas-clemente/quic-go https://github.com/lucas-clemente/quic-go [2]: https://caddyserver.com/docs/caddyfile/options#protocol https://caddyserver.com/docs/caddyfile/options#protocol
- jeffbee 5y agoDepending 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.
- deleted 5y ago[deleted]
- pgjones 5y agoHypercorn a Python ASGI server supports HTTP/3 built on aioquic which is a Python library supports QUIC. (I'm the author of Hypercorn).
- deleted 5y ago[deleted]
- isomorphic 5y agonginx has experimental QUIC support: https://quic.nginx.org/ https://quic.nginx.org/
- ivan4th 5y agoI 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... [1] https://www.openmptcprouter.com/ https://www.openmptcprouter.com/ [2] https://multipath-quic.org/ https://multipath-quic.org/
- avianlyric 5y agoWhy 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.
- deleted 5y ago[deleted]
- ivan4th 5y agoThere 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] [1] https://en.wikipedia.org/wiki/TCP_congestion_control https://en.wikipedia.org/wiki/TCP_congestion_control [2] http://sites.inka.de/bigred/devel/tcp-tcp.html http://sites.inka.de/bigred/devel/tcp-tcp.html
- Denatonium 5y agoI'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?
- jeffbee 5y agohttps://tools.ietf.org/html/rfc8899 https://tools.ietf.org/html/rfc8899
- Matthias247 5y agoBoth 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)
- willhoyle 5y agoI 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 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.
- jeffrogers 5y agoAre 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.
- Matthias247 5y agoQUIC 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.
- mleonhard 5y agoI 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.
- pmarreck 5y agoI’ve recently made Firefox Nightly my “main” browser. I’m quite impressed with it. Even imported my Chrome cookies AND logins
- Hard_Space 5y agoI 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.
- nextaccountic 5y agodoes it use neqo? https://github.com/mozilla/neqo https://github.com/mozilla/neqo
- throwaway189262 5y agoI'm not as excited about this as I was for HTTP/2 . Every benchmark I've seen is <5% performance improvement. I've heard the difference is larger on cellular networks with packet loss but haven't seen examples. What we need more than HTTP/3 is ESNI. Exposed server names are a real security risk.
- bawolff 5y agoIf you're looking at benchmarks without packet loss, then i'm not sure what you expect. Http/3 is almost entirely about that situation. ESNI is totally unrelated. People can work on more than one thing.
- throwaway189262 5y agoUnrelated 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
- bawolff 5y agoSure, 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.
- throwaway189262 5y ago> 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
- est31 5y agoBtw, the QUIC library that Firefox relies on is written in Rust: https://github.com/mozilla/neqo https://github.com/mozilla/neqo A bit weird though that they didn't cooperate with existing Rust quic stacks like quinn. https://github.com/quinn-rs/quinn https://github.com/quinn-rs/quinn
- pas 5y agoThe reason is the need to have total flexibility (control). [0] I reckon to make it as painless as possible to integrate it into Firefox. Also probably a tiny bit of not-invented-here syndrome too :) [0] https://github.com/mozilla/neqo/issues/81 https://github.com/mozilla/neqo/issues/81
- yonrg 5y agoIsn't syncthing using quic as one possible transport?
- BitPirate 5y agoYes, as UDP allows hole punching. They're using https://github.com/lucas-clemente/quic-go https://github.com/lucas-clemente/quic-go
- enz 5y agoI 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. [1]: https://github.com/enzzc/http-and-ip-indicator https://github.com/enzzc/http-and-ip-indicator (Beware, I don't maintain it actively)
- newman314 5y agoQUIC breaks Zscaler. See https://help.zscaler.com/zia/managing-quic-protocol https://help.zscaler.com/zia/managing-quic-protocol and Zscaler’s recommended solution. I look forward to no longer using Zscaler once Infosec finally realizes this.