Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The HTTP crash course nobody asked for

fasterthanli.me

Post reply on HN
Print view View original

131–140 of 149 posts

Re: The HTTP crash course nobody asked for

#131

Post by chris_wot »

chrismorgan wrote: post #127
superkuh wrote: post #120

Earlier quoted context omitted.

>Look, be real: the entire web is now built heavily on the CA model. No. You've just got your commercial blinders on. The entire *commercial web* is built on the CA model. But the commercial web is hardly all there is. There is a giant web of actual websites run by human persons out there that do not depend on CA TLS and who's use cases do not require dropping clear text connections. That's only a need for for-profit…

Pervasive monitoring is an attack. No public internet traffic of any character should be cleartext. The actual websites run by human persons that you speak of (such as myself) are not exceptions to this.

That seems like a societal problem.

Re: The HTTP crash course nobody asked for

#132

Post by X-Istence »

mgaunard wrote: post #129
X-Istence wrote: post #114

Earlier quoted context omitted.

There is not, which is what leads to vulnerabilities where two HTTP protocol parsers will parse the same request in two different ways (which led to the HTTP desync attacks). https://portswigger.net/research/http-desync-attacks-request... There's a reason why web servers will slam the door shut even when the client requests HTTP Keep Alive because they are unable to properly parse a request in a way that makes it saf…

The link shows how to exploit certain bugs in some bad implementations. That doesn't change the fact the protocol itself is quite well-defined. There is no serious HTTP server that wouldn't support keep-alive, this is just FUD.

You are conflating keep alive with http pipelining, they are not one and the same. Keep alive may be supported and servers may claim to have fully parses request 1 correctly so they can be fairly confident request 2 can be parsed correctly, but reading the spec one way or another and that is no longer a guarantee that holds.

Keep alive and http pipelining are supported by major servers, some with bugs or issues, but no clients pipeline requests (at least not the major browsers, curl and other popular tooling).

It’s not FUD, pipelining and reuse of an existing connection is broken in the face of trying to parse text protocols that don’t have well defined semantics and where implementations reading the same documentation provide different results because it’s not black and white, it’s fuzzy around the edges.

Re: The HTTP crash course nobody asked for

#133

Post by ameliaquining »

kevin_thibedeau wrote: post #126
rootusrootus wrote: post #80

Earlier quoted context omitted.

About half my personal (private, in my own home LAN) sites use self-signed certs that Chrome flat out won't accept. I have to type the magic key sequence to bypass the error. I do wish we could come up with something better for this kind of use case, then having to set up letsencrypt on my public domain and issue a wildcard cert to use with RFC1918 web sites. And that's without worrying about HTTP/3.

Use an empowered browser that lets you install your own private CA root.

Chrome does let you install your own private CA root. GP's problem sounds like a misconfiguration on the certificate-generation side.

Re: The HTTP crash course nobody asked for

#134

Post by ameliaquining »

bmitc wrote: post #106
chrismorgan wrote: post #31

Earlier quoted context omitted.

And this is why I expect HTTP/2 and HTTP/3 to be much more robust in the long term: the implementations are harder to write, and you won’t get anywhere without reading at least a some spec, whereas HTTP/1 is deceptively simple with therefore a lot of badly incorrect implementations, often with corresponding security problems.

> whereas HTTP/1 is deceptively simple with therefore a lot of badly incorrect implementations Doesn't that imply that HTTP/1 is deceptively complex?

I think the idea is that HTTP/1 is simple in the hello-world 5th-percentile-complexity case, which deceives people into thinking that it's also simple in the real-world 99.9th-percentile-complexity case, which it's not at all.

Re: The HTTP crash course nobody asked for

#135

Post by skrtskrt »

insanitybit wrote: post #116
rootusrootus wrote: post #80

Earlier quoted context omitted.

About half my personal (private, in my own home LAN) sites use self-signed certs that Chrome flat out won't accept. I have to type the magic key sequence to bypass the error. I do wish we could come up with something better for this kind of use case, then having to set up letsencrypt on my public domain and issue a wildcard cert to use with RFC1918 web sites. And that's without worrying about HTTP/3.

Add the certificate to your trusted store? HTTP3 will change nothing about this.

Yeah this is just a browser setting - this complaint sounds in bad faith coming from someone who apparently knows about all the other aspects of using certs?

Re: The HTTP crash course nobody asked for

#136

Post by X-Cubed »

rootusrootus wrote: post #80
insanitybit wrote: post #76

Earlier quoted context omitted.

Can you not just have it use a self signed certificate? I don't see why a CA would need to be involved at all, nor can I even imagine how that could be enforced at the protocol level. This sounds like a red herring to me. edit: Yeah I've more or less confirmed that self signed certs are perfectly fine in HTTP3. This is a big ball of nothing.

About half my personal (private, in my own home LAN) sites use self-signed certs that Chrome flat out won't accept. I have to type the magic key sequence to bypass the error. I do wish we could come up with something better for this kind of use case, then having to set up letsencrypt on my public domain and issue a wildcard cert to use with RFC1918 web sites. And that's without worrying about HTTP/3.

I suspect you're missing the subjectAltName field from your certificate(s).

https://developer.chrome.com/blog/chrome-58-deprecations/#re...

Re: The HTTP crash course nobody asked for

#138

Post by mannyv »

As far as i can tell the host header is pointless, because if it's ssl/tls you won't be able to read it and route it. That's what sni is for. If you aren't tls then you don't need it, unless you hit the server as an ip. But then why would you do that?

Re: The HTTP crash course nobody asked for

#140

Post by LukeShu »

mannyv wrote: post #138

As far as i can tell the host header is pointless, because if it's ssl/tls you won't be able to read it and route it. That's what sni is for. If you aren't tls then you don't need it, unless you hit the server as an ip. But then why would you do that?

It's for one server/IP serving multiple hostnames. For instance, the same physical server at 45.76.26.79 serves both www.lukeshu.com and git.lukeshu.com with the same instance of Nginx. Once Nginx decrypts the request, it needs to know which `server { … }` block to use to generate the reply.

With TLS+SNI, this is redundant to the name from SNI. But we had TLS long before we had SNI, and we had HTTP long before we had TLS, and both of those scenarios need the `Host` header.

Post reply on HN