7 ms·
The Illustrated QUIC Connection
- pcthrowaway 4y agoDoes anyone understand how TLS is happening over UDP? I thought TLS was a TCP-based protocol
- deleted 4y ago[deleted]
- nielsole 4y agoQuic can have multiple streams. Every stream is guaranteed to be ordered like TCP. The TLS is wrapped in "CRYPTO-frames" whose content is passed verbatim to TLS. Quic does require collaboration with TLS. There are a couple of events in which TLS calls the Quic implementation, for example for TLS state changes. What I dont quite get is how the individual streams are encrypted. As I understood it, the initial vector(IV) is generated during the initial handshake, so all the streams would reuse the same IV which could make it leak the requested file.
- Dylan16807 4y agoI'm reasonably sure that the encryption uses packet numbers, which are global across the entire connection.
- syncsynchalt 4y agoEach endpoint maintains a packet number, starting at 0 and increasing by one for each packet sent. This is an input to the packet encryption IV. Note that unlike TCP retries do not re-use the packet number, they get a higher packet number on re-transmit. This lets endpoints differentiate packet retries from delayed packets, which isn’t possible in TCP (and the ambiguity of which is a problem in TCP stacks that want to react differently to each).
- TickleSteve 4y agoThere is a separate standard for TLS over UDP, namely DTLS which is unrelated to QUIC. (https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security https://en.wikipedia.org/wiki/Datagram_Transport_Layer_Secur...) TLS is not TCP specific. DTLS is regularly used in IoT applications such as smart metering where the overhead of a TCP stack is costly.
- ThePhysicist 4y agoIt's almost identical to TLS over TCP, the main difference is that QUIC is responsible for reliable delivery of packets/frames once the TLS handshake is complete. The handshake itself is done in a special CRYPTO frame [1]. 1: https://greenbytes.de/tech/webdav/draft-ietf-quic-tls-latest.html#carrying-tls https://greenbytes.de/tech/webdav/draft-ietf-quic-tls-latest...
- syncsynchalt 4y agoIronically TLS is not suited to TCP. TLS is record-based, and the stream-based TCP doesn’t have record boundaries. TLS-over-TCP solves this by sending TLS records with a type-and-length byte header. QUIC uses UDP which is more record based, and sends TLS records encapsulated in QUIC packets.
- Matthias247 4y agoyes and no. The TLS records are transmitted in CRYPTO frames, which form a crypto stream (just like a TLS stream) that is more or less transparent to the QUIC stack. QUIC implementations forward an arbitrary datastream from the peer into the TLS library, and place the data that is produced by that stack again onto the ordered bytestream. There's no record layer for CRYPTO streams - that one would again be above on the TLS layer.
- superkuh 4y agoA protocol that only works on the whim of a third party corporate person is not optimal for human people. Baking in a requirement of CA based TLS is not great. >TLS: Certificate, the certificate for this host, containing the hostname, a public key, and a signature from a third party asserting that the owner of the certificate's hostname holds the private key for this certificate
- dagenix 4y agoAnd your solution is?
- octoberfranklin 4y agoDNSCurve's self-authenticating domains: https://en.m.wikipedia.org/wiki/DNSCurve https://en.m.wikipedia.org/wiki/DNSCurve It's like "onion URLs" without the rest of Tor. Or like b32.i2p domains without the rest of I2P.
- jmprspret 4y agoI hope to god this catches on. At this rate it won't, because a FAANG company isn't supporting it. But I still hope somehow it will catch on. DJB's work is fantastic and this is no exception.
- vbezhenar 4y agoI don't believe it will catch on. Consumers don't care about security. Engineers do, but not at expense of usability.
- superkuh 4y agoIt's very simple. Allow not using encryption. Plain text + encrypted make a great team. Either by themselves is not great.
- 3np 4y agoYou can generate your own root cert and self-sign. No need for third-parties.
- neatze 4y agoDo any browsers API's support quic ?
- bejelentkezni 4y agohttps://caniuse.com/http3 https://caniuse.com/http3
- ignoramous 4y agoLatest Chrome and Firefox both do. Make sure the server sends h3 with the alt-svc (http) header and adds h3 to the (tls v1.3) alpn. The browser may connect to h1 or h2 endpoints at first, then upgrading it to h3 for subsequent connections where supported (provided, the firewall isn't blocking QUIC). https://tools.ietf.org/id/draft-ietf-quic-http-23.html#rfc.section.3 https://tools.ietf.org/id/draft-ietf-quic-http-23.html#rfc.s...
- tialaramex 4y agoAlthough the newer HTTP protocols have ALPN names like h2 and h3, the older ones are named http/0.9, http/1.0 and http/1.1
- neatze 4y agoI mean if I can access it from javascript, like webrtc.
- aseipp 4y agoChrome actually has deployed a version of WebTransport, which is basically a way of using QUIC directly from the browser for datagram/stream connections (e.g. to implement game networking, in browser.) But it's relatively new, and you need to modify the QUIC stack in order to accept and handle WebTransport connections; so it doesn't "just work" out of the box with any popular QUIC libraries I know of. It's unclear where this will all end up right now; you'll probably have to wait a bit for it to be production ready. But there's clearly broad interest in the topic, though.
- Matthias247 4y ago
- klabb3 4y agoQuic is a great protocol but IIUC you have to apply a user space library for things that normally (TCP) is kernel/hardware. Well, at least in my own experiments with a Golang implementation, I've seen CPU be the bottleneck for high bandwidth transfers (MTU is ~1300b). Add to that that common OS:s don't give you a particularly large UDP receive buffer, which can cause a BDP bottleneck for high latency connections.
- JoshTriplett 4y agoThere's no fundamental reason quic couldn't happen in kernel-space, it just hasn't been done yet.
- SquareWheel 4y agoThat's true, and maybe lower-level optimizations will start to emerge. But I suspect QUIC was intentionally left in userspace to allow for more rapid development. Indeed there are already many libraries available which means you can use it today. If we had to wait for kernels and middleware to support it, that might still be years out.
- JoshTriplett 4y agoI agree, and I think userspace development was a good idea. I also don't think it needs to stay in userspace forever. In particular, ideally we'll have kernel support that allows for more capable userspace stacks to run, and also allows just opening a socket.
- stiglitz 4y agoMsquic can be built as a driver. https://github.com/microsoft/msquic/blob/main/msquic.kernel.sln https://github.com/microsoft/msquic/blob/main/msquic.kernel....
- oconnor663 4y agoThe TLS 1.3 explanation (https://tls13.ulfheim.net https://tls13.ulfheim.net) and others on the same site are also excellent.
- lamontcg 4y agoHaving lived through a production datacenter meltdown due to software engineers throwing away TCP, along with stuff like slow start and congestion control, and obliterating ethernet switch buffers with UDP, I'm a bit concerned as to how QUIC is supposed to be used in order to avoid that? If your fabric has end-to-end flow control this would be fine, but this seems like it could be greatly misused and should come with some warning labels.
- Dylan16807 4y agohttps://web.archive.org/web/20220328033933/https://datatracker.ietf.org/doc/html/rfc9002 https://web.archive.org/web/20220328033933/https://datatrack... They copied directly from TCP and made several adjustments to improve signalling.
- lamontcg 4y agoOh that's a relief. Looks like someone finally did the "lets replace TCP with UDP" job right. And it looks like a hell of a lot of work.
- syncsynchalt 4y agoThat’s the hope, anyway. It’s hard to compete with decades of TCP refinement but at least there’s some big guns behind making this work. There’s a lot of thought that has gone into QUIC and the protocol has several rules and mechanisms to prevent problems, such as the 3x amplification limit. Both the browser authors and server side (e.g. google) are on the lookout for problems and how they can improve on them.
- deleted 4y ago[deleted]
- teleforce 4y agoThere's a new Homa protocol specifically designed for data center to replace TCP by Ousterhout (TCL/TK and Raft author). Ousterhout is now looking for people to test the Homa protocol for the data center to improve its implementation [1]. [1]Linux implementation of Homa, a protocol to replace TCP for low-latency RPC: https://news.ycombinator.com/item?id=28440542 https://news.ycombinator.com/item?id=28440542
- syncsynchalt 4y agoAuthor here; let me know if there are any comments or questions I can answer.