You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
TLS Early Data / 0-RTT lets a TLS client send a small payload (typically < 16kB) along with its initial handshake, when opening a TLS session to a previously known host.
With TLS 1.3 session resumption + TLS 0-RTT (and TCP Fast Open), an HTTP request/response could be made in a single roundtrip.
The obvious and (too) often quoted downside of 0-RTT is that 0-RTT can be replayed (much like QUIC's 0-RTT).
In the context of Hitch + Varnish, ie TLS 0-RTT x HTTP, it would be great to support TLS 0-RTT for idempotent requests, in order to reduce latency (which is a key aspect of an HTTP cache).
An ideal implementation would probably pass the backend (well, Varnish, to name it) the HTTP request in the early data, along with some way for Varnish to know if this is early data (maybe using PROXY protocol fields); so that a user in the VCL could then add some if tls.early_data: ... synth 425 (see the RFC linked above).
But I think that many caches serve almost exclusively idempotent requests; and just enabling 0-RTT unconditionally and passing that data to the backend would be very useful for reducing latency, while keeping it simple.
In other words, I'd like to have a zero-rtt = on configuration option that can be enabled per frontend; which when enabled just passes any early data to the backend.
Apparently this is not too difficult to implement: SSL_CTX_set_recv_max_early_data(ctx, 16384) to tell OpenSSL we accept early data; then before SSL_read we SSL_read_early_data until it is FINISHED, accumulate that into a buffer and pass it to the backend.
Hi,
TLS Early Data / 0-RTT lets a TLS client send a small payload (typically < 16kB) along with its initial handshake, when opening a TLS session to a previously known host.
With TLS 1.3 session resumption + TLS 0-RTT (and TCP Fast Open), an HTTP request/response could be made in a single roundtrip.
The obvious and (too) often quoted downside of 0-RTT is that 0-RTT can be replayed (much like QUIC's 0-RTT).
In the context of Hitch + Varnish, ie TLS 0-RTT x HTTP, it would be great to support TLS 0-RTT for idempotent requests, in order to reduce latency (which is a key aspect of an HTTP cache).
An ideal implementation would probably pass the backend (well, Varnish, to name it) the HTTP request in the early data, along with some way for Varnish to know if this is early data (maybe using PROXY protocol fields); so that a user in the VCL could then add some
if tls.early_data: ... synth 425
(see the RFC linked above).But I think that many caches serve almost exclusively idempotent requests; and just enabling 0-RTT unconditionally and passing that data to the backend would be very useful for reducing latency, while keeping it simple.
In other words, I'd like to have a
zero-rtt = on
configuration option that can be enabled per frontend; which when enabled just passes any early data to the backend.Apparently this is not too difficult to implement:
SSL_CTX_set_recv_max_early_data(ctx, 16384)
to tell OpenSSL we accept early data; then before SSL_read weSSL_read_early_data
until it isFINISHED
, accumulate that into a buffer and pass it to the backend.Then a test would probably openssl s_client with
-early_data
:The text was updated successfully, but these errors were encountered: