I was researching on QUIC protocol and my professor asked me this question. QUIC is said to be built on UDP and uses TLS packets. TLS itself requires reliable connection that is TCP. So, why QUIC is not said to be built on TCP?
PS: Please correct me if my concepts are wrong and if possible, please explain in deep how QUIC packets work.
QUIC is said to be built on UDP and uses TLS packets.
QUIC (RFC 9000) does not use TLS "packets".
Technically, TLS uses the term "record" to indicate a block of bytes that defines how the protocol is framed. A record specifies the TLS protocol version, the length of the record, etc.
Inside TLS frames there are one or more TLS messages that specify cryptographic information or commands.
The TLS records are transported by TCP.
What QUIC does instead is to reuse some of the TLS messages, but nothing of the TLS record layer.
For example, in TCP the first bytes sent by a client are typically a TLS record that wraps the ClientHello message.
In QUIC, instead, the first bytes are a QUIC Initial packet, that wraps a CRYPTO frame, that wraps the ClientHello message, and all of these bytes must fit into a UDP datagram (they typically do, and the Initial packet even carries a PADDING frame to make the initial bytes at least 1200).
Refer to RFC 9001 for more details about how TLS is used in QUIC.
More broadly about QUIC, it is based on UDP but borrows many TCP features (retransmissions, flow control, etc.) that basically make it an alternative to TCP in the sense that it is a reliable network protocol, with additional security (encryption) features built-in, borrowed by TLS.
TCP is clear-text and relies on TLS layered on top to provide encryption.
QUIC is a mix of TCP features and TLS features (there is no clear-text QUIC), without layering.
When you say "Why QUIC is not said to be built on TCP?", I say "QUIC is not built on TCP, it is built on UDP. However, QUIC borrows TCP features that make QUIC provide similar functionalities as TCP, in particular reliability and flow control, that are not provided by UDP".
For example, in Jetty we have implemented HTTP/1.1 and HTTP/2 (that are TCP-based protocols) on top of QUIC, using a single, persistent, QUIC stream.
This shows that QUIC can be indeed a replacement for TCP, as it can carry protocols that were designed for TCP.
QUIC includes TLS in it to allow it to be used over UDP in the same way as TCP works.
Why bother reinventing TCP and not just use TCP? Well TCP is kind of “stuck” as it’s slow to roll out new changes that fundamentally change how TCP works. Enhancing it to allow new features like multiplex streams will take a loooong time to roll out everywhere TCP is supported.
QUIC is built over simple UDP packets and everything else is handled at either end by QUIC and all the routers and networks in the middle don’t need to know about these new QUIC features.
The RFCs are all written by committee, and the structure and language is often confusing, so it is easy to mix things up.
A full TLS implementation requires a reliable transport, which as of today is provided by TCP and SCTP (RFC3436).
QUIC (RFC9001) doesn't actually require a full TLS implementation though, and instead simply re-uses parts of the TLSv1.3 standard:
4.1. Interface to TLS
As shown in Figure 4, the interface from QUIC to TLS consists of four
primary functions:
* Sending and receiving handshake messages
* Processing stored transport and application state from a resumed
session and determining if it is valid to generate or accept 0-RTT
data
* Rekeying (both transmit and receive)
* Updating handshake state
So, given the above, the actual process that QUIC takes to encrypting the packet data isn't TLS at all, but is instead provided by QUIC.
Related
I understand that TLS requires a reliable transport but following the TCP/IP model the first layer in case of sending data/request would be Application layer ... After connection established and the data is ready it moves to the next layer which is the Transport layer for the TCP header to be added.
So the first step after the DNS would be the TCP handshake then up to TLS handshake then down to TCP again to add the TCP header ? OR I'm missing something here ?
The problem with layer models is that there are too many cases when there are either too many or not enough layers. It is important to understand the concept of layers, and why do we need one. But IMHO, neither of the layer models are actually representing the Internet.
As already said in comments, DNS is a separate "application" from the standpoint of what you are describing. So, whether DNS is happening or not does not have an affect of what happens next.
I think this figure shows the layer model with TLS in it (source).
Application is passing its data to TLS layer. This layer is usually implemented as a library that is linked with the application, so it is also "above" sockets.
TLS works on top of TCP, that is TLS gives encrypted stream along with its own signaling packets to TCP and TCP processes them as any other packets.
So, basically it is how you describe. First, a TCP connection is established. After which TCP just sends whatever stream of data TLS is giving it, and this stream starts with a TLS handshake.
There is one nuance though. TCP is a stream based protocol. It accepts stream on one side and returns stream on the other side. Dividing the stream into packets is happening in TCP itself. That is TLS is using "records" of any size which are convinient to TLS. The records do not necessary correspond with packets.
Can someone point me to some documentation on how to implement a Bittorrent UDP application?
I am working on a Bittorrent application and I can successfully download using TCP but I want to implement UDP and I can't find any information on it. I am retrieving peers with UDP trackers but that approach appears different than downloading files.
If I sniff a UDP Handshake I see the following in Wireshark:
172.16.49.213 5.31.44.30 UDP 62 35507 → 18318 Len=20
5.31.44.30 172.16.49.213 UDP 62 18318 → 35507 Len=20
This is done before the handshake. Also, it looks like there are 20 bytes prepended to the Handshake (different than the 20 bytes above).
So I need some information to help me with what all this means.
The BitTorrent Peer Wire Protocol over UDP, called uTP is specified in:
BEP29 - uTorrent transport protocol
BitTorrentInc has also published uTP as a IETF RFC were they call it LEDBAT:
RFC 6817 - Low Extra Delay Background Transport (LEDBAT)
However, I wouldn't recommend anyone to do their own implementation, (except as a learning experience), as it involves a lot of time critical, low level network IO and is very tricky to get right.
Instead I recommend to use the library: https://github.com/bittorrent/libutp
Almost all clients implementing uTP uses this library. AFAIK, the only exception is libtorrent/rasterbar (used by qBittorrent and Deluge) and it don't work as good as libutp does.
I am trying to do some tests in Chromium with HTTP/2, HTTP1.1, QUIC, and TCP. I want to try different combinations of the protocols. I am experiencing some very strange behaviour in my browser though. When I want to try HTTP1.1+QUIC I start my browser with:
chromium-browser --disable-http2 --enable-quic
And I can see at chrome://net-internals/ that HTTP2 is disabled and QUIC is enabled. However, when I do a web request to a server supporting HTTP2 and QUIC I get this:
Why would it say that the HTTP/2 is used when it so clearly says that http2 enabled: false at chrome://net-internals/ ?
I have previously been successful in running HTTP1.1 with QUIC. Has QUIC been updated to only work with HTTP/2? Or does the 'Protocol'-field display the wrong protocol?
I would love to if someone else have been successful is using QUIC with HTTP1.1
Many thanks!
QUIC only works with HTTP/2 and doesn’t make sense with HTTP/1.1.
HTTP/1.1 sends one request at a time on its one TCP connection. Browsers open 6-8 connections to allow some level of parallelisation but, other than that hack, HTTP/1.1 is basically synchronous - you send a request and can’t use that connection again until that request is responded to in its entirety. So HTTP/1.1 has a Head of Line (HOL) blocking problem as a slow, or delayed, response will block the connection so it can’t be used for a resource that could be responded to.
HTTP/2 is a binary, multiplexed protocol, which basically means requests and responses are split into packets which can be sent on a single TCP connection and intermingled. This is great as TCP connections are relatively expensive over the Internet due to the time to set up the TCP connection, to set up HTTPS potentially on top of that and then to build up the TCP slow start rate limiting window to an optimal size. So HTTP/2 being able to send and receive multiple HTTP requests and responses over one TCP connection is a massive improvement and solves the HOL Blocking problem at a HTTP level.
Unfortunately the HOL blocking problem is moved from HTTP layer to TCP layer. TCP is a guaranteed protocol - if a single TCP packet is lost then it is re-requested and the whole connection waits for that missed packet to come back. This is great as higher level protocols (like HTTP) can build upon this without worry about checking if pieces have made it or not or in the right order - TCP takes care of that. The downside with this is that protocols like HTTP/2 may not need this strict level of guarantees. If a server is sending 6 HTTP/2 responses on one connection at the same time, and one TCP packet gets dropped it will only be for one of those responses - the other 5 could in theory continue to be sent and then be processed by the browser. But TCP forbids this.
So QUIC aims to solve this by replacing the TCP part with a UDP based protocol that guarantees delivery at a stream level rather than a connection level. This could have been done by enhancing TCP but that’s so embedded into lots of servers, clients, operating systems, network infrastructure... etc. that it was easier to build upon UDP instead. Eventually learnings from this might be incorporated into TCP. Until then QUIC allows quick experimentation and innovation as UDP is very, very light and any additions to it (e.g. delivery guarantees) are basically implemented in the user-space land rather than lower level internals where it can’t be upgraded. QUIC will likely eventually be used for protocols other than HTTP but for the moment that’s it’s primary use case.
So QUIC effectively replaces the TCP part, but it also needs to change the lower level parts of HTTP/2 which means it also needs to implement the in between TLS part. The best diagram for explain it’s place is this diagram (taken from this presentation):
I have previously been successful in running HTTP1.1 with QUIC.
I seriously doubt this. As per above explanation QUIC only makes sense over a multiplexed protocol like HTTP/2. Perhaps Chrome used to call it QUIC rather than HTTP/2 + QUIC but it would always have been using HTTP/2 (or its similar predecessor SPDY).
Also HTTP/2 really only changes how the messages are sent on the wire. At a higher level, as used by web developers and users, it often acts the same way as HTTP/1.1 with the same verbs (GET, POST... etc.) and HTTP Headers (mostly). So since QUIC just improves how those HTTP/2 messages are sent on the wire, rather than the higher level “HTTP” protocol it really doesn’t make sense to discuss or measure how HTTP/1.1 over QUIC (if it did exist) would differ from HTTP/2 over QUIC - since HTTP/1.1 over QUIC would basically become HTTP/2 over QUIC.
Finally when QUIC has completed standardisation (as opposed to the non-standard Google QUIC version often called gQUIC), it will use a modified version of HTTP/2 which will be called HTTP/3. For now browsers will only use gQUIC and HTTP/2.
If you want a quick test, head to https://http3.is.
It’s a test website created by fastly.
I have a sensor node which broadcast sensor data as UDP packets to a specific port. I have to secure this broadcast. I tried to find out how can I achieve that and found out that DTLS is the answer.
What all do I need to do to implement DTLS? Initially, I thought I do not need certificates, however, I learnt that DTLS is also using handshake to exchange keys. Do I need to create certificates for that ?
DTLS is a version of TLS (which is end-to-end security) used over UDP or other unreliable packet delivery mechanism. DLTS can not be used with broadcasting which is unidirectional.
Now, what is "secure" in your case? Do you need to encrypt the data? But encryption is a concept which is contrary to broadcasting (as the number of recipients grows, security drops exponentially). Signing of data is possible. It is of course possible to encrypt the data for one or multiple recipients (using either symmetric encryption or public-key encryption) but again this is hardly a broadcast and has nothing to do with UDP itself (or other transport).
What is the functional difference between TLS and DTLS?
How does application flow/negotiation differ while using TLS vs DTLS?
Basically DTLS is to construct TLS over datagram (UDP, DCCP, etc.)
DTLS is similar to TLS intentionally except that DTLS has to solve two problems: packet lost and reordering. DTLS implements
packet retransmission
assigning sequence number within the handshake
replay detection.
See RFC 6347 for details.
The idea is that DTLS is to TLS as UDP is to TCP, as much as possible.
See https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/ which will likely obsolete RFC 6347 for details on the specification, as well as links to discussions thereof.
There are key differences between DTLS and the Transport Layer Security (TLS) protocol that the application programmer needs to be aware of that other answers miss/imply do not exist!
The DTLS protocol provides communications privacy for datagram protocols. Contrary to the extant top-rated answers as of this writing(archive), DTLS is not an implementation (or "construct") of TLS over UDP (or datagram protocols in general), and, replay detection is a required feature of TLS, but optional in DTLS. DTLS includes an implementation of a very TLS-like handshake, modified to work over datagram protocols. The implementation does handle the problems of packet reordering and loss, but only for the packets used for the DTLS handshake (and cipher selection). In other words, the "flights" that these packets deliver are delivered reliably. However, the DTLS packets containing payload (application data) may deliver their payload no more reliably than the DTLS packets (typically UDP) that encapsulate them.
Furthermore, while the DTLS protocol (v1.2) is derived from the TLS protocol (v1.2) and claims to "provide equivalent security guarantees", it does not.2 Back in 2013, researchers identified major security shortcomings in both DTLS implementations and in the DTLS protocol itself, that have since been rectified, at least in GnuTLS and OpenSSL implementations.2 In addition, DTLS does not guarantee non-replayability.
Finally, the OP asks how application flows differ while using TLS vs DTLS. TLS is intended to deliver a stream of data reliably and with authenticated encryption, end-to-end. DTLS is intended for the delivery of application data that is authenticated and encrypted end-to-end, but with lower latency than can be achieved when all application data delivery is guaranteed. This is why DTLS is used to secure streaming applications where losses are less important than latency, e.g. VoIP, live video feeds and MMO gaming.
PS: DTLS 1.3 is done/will probably have been published as an RFC by the time you read this.3
PPS: Oh, and if this was worth reading, don't miss RFC 7457, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)". I'm surprised DTLS 1.3 (the final draft anyway) doesn't refer to it (such as from its Security Considerations section) (Suggested) and neither does the TLS 1.3 spec!
DTLS is an implementation of TLS over UDP (a datagram protocol). per wikipedia, TLS uses TCP, and DTLS uses UDP, so all the classic differences apply. UDP communications exist as streams of packets with no ordering, delivery reliability, or flow control. applications that use datagram protocols need to make sure they can handle these concerns internally.
https://en.wikipedia.org/wiki/Transport_Layer_Security#Applications_and_adoption
http://www.diffen.com/difference/TCP_vs_UDP
One difference is that, due to being over UDP, stream ciphers are not allowed:
4.1.2.2. Null or Standard Stream Cipher
The DTLS NULL cipher is performed exactly as the TLS 1.2 NULL
cipher.
The only stream cipher described in TLS 1.2 is RC4, which cannot be
randomly accessed. RC4 MUST NOT be used with DTLS.