HTTP STATUS 425

[miqui]

hi Community,

..i found this - https://evertpot.com/http/425-too-early   and it makes sense (mostly), but can anyone here elaborate on this status code if you have used it in any of your API work?

...specially the part about 

"There are ways for clients to optimize this setup by sending a bunch of data very early in the process, before the full TLS connection is completely setup."

...thanks..

rgds,

Miguel

[David Waite]

Sure, TCP and HTTPS require several round-trips of setup. This is why we have gotten HTTP/2, which allows you to stream multiple requests over a single TCP connection. It is one of the reasons they are working on QUIC, which reduces the latency for setting on TCP and allows the data streams to continue when things like your IP address change.

And it is the reason for TLS 1.3 Early Data (aka 0-rtt) - 40% of TLS setups are not new, but resuming an existing relationship between the client and server. With early data, you can send a request to resume TLS and send request data at the same time (such as a HTTP request). This avoids a round-trip.

When you consider higher latency connections like mobile phones and satellite connections, and you consider a lot of websites load data from multiple servers, all of these technologies are meant to attack the substantial (in some cases multi-second) loading time for pages.

However, there is a catch with TLS early data. Since the crypto for the new connection isn't negotiated until the server responds, any third party that captures your encrypted request can rebroadcast it themselves, potentially multiple times. This may also include intermediaries, such as reverse proxies and edge caching CDNs, even if the client isn't using TLS 1.3 early data itself.

For this reason, it is important that the requests send via early data have certain security properties. Most notably is that they need to be idempotent - the request being sent multiple times (even out of sequence, aka PUT DELETE PUT) should not result in an issue. GET is usually fine, POST is usually wrong. 

So it isn't so much that there is "too much" early data, but that the types of requests being made don't have the right security properties.

The 425 arrives on a response for the server, so by the time your client sees the response that the request failed, the TLS connection is fully set up, with the full set of security properties. So the client just needs to repeat the request to have it accepted (or fail via more traditional codes).

Some services will never support early data, since it introduces a new class of security concerns that layer between the transport and application/api layers. Others like Google have (IIRC) committed to turning it on for their entire infrastructure for the network traffic and user experience benefits. There are also other TLS features which are incompatible with 0-rtt.

From an API client perspective, a 425 indicates you could improve network performance by changing how you interact with that API/service. You shouldn't get this error unless they have enabled 0-rtt, so presumably they have also worked out which API calls are appropriate within early data.

From an API server perspective, early data is usually indicated via a the Early-Data HTTP header. If the client does not support the header, an intermediary or framework may still add it so backend systems can have their own policy on whether the request is OK. However, systems may just have static policies - for instance, a CDN or other static asset server will typically default to allow GET requests, and 425 all others.

 

-DW

[miqui]

..cool..... thanks DW..

[RestIsSexy]

wow what an awesome explanation !