4 ms·

Does anyone understand how TLS is happening over UDP? I thought TLS was a TCP-based protocol

deleted 4y ago
[deleted]
nielsole 4y ago
Quic 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 ago
  I'm reasonably sure that the encryption uses packet numbers, which are global across the entire connection.
- syncsynchalt 4y ago
  Each 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 ago
There 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 ago
It'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 ago
Ironically 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 ago
  yes 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.

deleted 4y ago

[deleted]

Quic 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 ago
I'm reasonably sure that the encryption uses packet numbers, which are global across the entire connection.
syncsynchalt 4y ago
Each 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 ago

There 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 ago

It'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 ago

Ironically 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 ago
yes 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.