Major HTTP flaw puts 24 million websites at risk​ | Cybernews (cybernews.com)
from kid@sh.itjust.works to cybersecurity@sh.itjust.works on 14 Aug 12:18
https://sh.itjust.works/post/44074733

#cybersecurity

threaded - newest

tux0r@feddit.org on 14 Aug 12:21 next collapse

Also, that website uses Cloudflare to “protect” itself, risking reliability for no good reason at all.

Cheradenine@sh.itjust.works on 14 Aug 14:26 collapse

Am i missing something? It seems like they are only trying a DNS redirect. I am not a fan of those or of Cloudflare, but in the scheme of things that seems relatively benign. On Android that’s easily blocked by my firewall rules.

I’m no expert and would like to be educated on this.

tux0r@feddit.org on 14 Aug 14:49 collapse

Cloudflare does have its own history of outages.

Cheradenine@sh.itjust.works on 14 Aug 15:05 collapse

Yes it does, what does that have to do with what I asked? I do appreciate your downvote when I asked a legitimate question.

tux0r@feddit.org on 14 Aug 15:14 collapse

I’m not exactly a fan of irregular downvotes, actually.

What I’m saying is: a website that relies on any Cloudflare service will have an outage when Cloudflare does. Cloudflare adds a single point of failure heee, and in my opinion that’s irresponsible.

Cheradenine@sh.itjust.works on 14 Aug 15:50 collapse

I’m not exactly a fan of irregular downvotes, actually.

Yet you did it anyway. I didn’t downvote you, I only asked a question to learn more.

I still have not learned anything about this.

I agree with you about Cloudflare gatekeeping. I also use Tor or Orbot, so Cloudflare is a pain in the ass.

sugar_in_your_tea@sh.itjust.works on 14 Aug 15:03 collapse

Yeah, this isn’t really a problem w/ HTTP/1.1, it’s a problem with servers being loose w/ the spec. The example they gave was having a fixed content length and chunked encoding in the same request, which is nonsensical and should be rejected. The spec doesn’t mention what happens if you have both, but it does distinguish between having one or the other, so it makes sense to reject the request if there’s confusion.

That said, the spec does indicate a priority here:

4.4 Message Length

The transfer-length of a message is the length of the message-body as it appears in the message; that is, after any transfer-codings have been applied. When a message-body is included with a message, the transfer-length of that body is determined by one of the following (in order of precedence):

1.Any response message which “MUST NOT” include a message-body (such as the 1xx, 204, and 304 responses and any response to a HEAD request) is always terminated by the first empty line after the header fields, regardless of the entity-header fields present in the message.

2.If a Transfer-Encoding header field (section 14.41) is present and has any value other than “identity”, then the transfer-length is defined by use of the “chunked” transfer-coding (section 3.6), unless the message is terminated by closing the connection.

3.If a Content-Length header field (section 14.13) is present, its decimal value in OCTETs represents both the entity-length and the transfer-length. The Content-Length header field MUST NOT be sent if these two lengths are different (i.e., if a Transfer-Encoding header field is present). If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.

4.If the message uses the media type “multipart/byteranges”, and the transfer-length is not otherwise specified, then this self- elimiting media type defines the transfer-length. This media type UST NOT be used unless the sender knows that the recipient can arse it; the presence in a request of a Range header with ultiple byte- range specifiers from a 1.1 client implies that the lient can parse multipart/byteranges responses.

A range header might be forwarded by a 1.0 proxy that does not understand multipart/byteranges; in this case the server MUST delimit the message using methods defined in items 1,3 or 5 of this section.

  1. By the server closing the connection. (Closing the connection cannot be used to indicate the end of a request body, since that would leave no possibility for the server to send back a response.)

If all services followed the spec, there shouldn’t be an issue.

HTTP/2 is better, sure, but the real problem here isn’t HTTP 1.1, the problem is implementations, and there are surely issues in the HTTP/2 implementations we have on the market today…