Live data from Hacker News

The HTTP crash course nobody asked for

fasterthanli.me

121–130 of 149 posts

Re: The HTTP crash course nobody asked for

#122

> HTTP/1.1 is a delightfully simple protocol, if you ignore most of it. As someone who had to write a couple of proxy servers, I can't express how so sadly accurate it is.

> As someone who had to write a couple of proxy servers, I can't express how so sadly accurate it is.

Chunked transfer/content encoding problems still give me nightmares...

Re: The HTTP crash course nobody asked for

#123

Earlier quoted context omitted.

HTTP/3 is written for the use case of large corporations and does not even allow for human persons to use it alone. It requires CA based TLS to set up a connection. So if you want to host a website visitable by a random person you've never communicated with before you have to get continued permission from an incorporated entity running a CA to do so. This is far more of a security problem than all of the bad HTTP 1.1…

Your complaint is strictly social, and quite irrelevant here. Look, cleartext internet protocols are on the way out, because their model is fundamentally broken. For security reasons, I will note, and privacy. There, we joust security against security. Cleartext HTTP/1 is strictly a legacy matter, retained only because there’s still too much content stuck on it. But browsers will be more aggressively phasing it out s…

> If free issuance of certificates falters, the internet as we know it is in serious trouble. Deal with it. Social factors. This might conceivably happen, and if it does, HTTP/1 will not save you.

This (HTTP/1 won't save us) doesn't seem entirely accurate to me.

I can run free, untrusted HTTPS easily using self-issued certificates. It's relatively simple to think of mechanisms where trust can be layered on top of that outside the traditional CA mechanisms (think Keybase derivatives like DID-systems). It's a small patch to allow that alternative trust framework to be used for HTTPS.

I don't know HTTP/3 at all, but if it is more tightly tied to CA infrastructure that is a problem.

Re: The HTTP crash course nobody asked for

#124
post #83

Earlier quoted context omitted.

> I will believe this when I see it, thank you I'm on my phone so I can't confirm this is http3, but how about https://self-signed.badssl.com/

ok $ curl -v https://self-signed.badssl.com/ * Trying 104.154.89.105:443... * Connected to self-signed.badssl.com (104.154.89.105) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.0 (OUT), TLS header, Certificate Status (22): * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS header, Certificate Status (22): *…

This seems like it... works exactly as intended?

If you decide you trust that certificate (which can be a legitimate thing to do - the cert signature could be communicated to you via out-of-band trusted mechanisms) then https://curl.se/docs/sslcerts.html explains how to trust it.

Re: The HTTP crash course nobody asked for

#125

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 wish there was an intermediate AH mode. the page is signed but not encrypted.

Or baring that I wish that browsers would ease up a bit and make tofu style self signed certs acceptable.

I really don't like how there is an expire time built into tls sites. Have you ever found someones old site, usually hosted by a university, that just lives year after year like a time capsule. well not gonna happen with tls.

And on the subject of CA's I don't think I trust them any more than a tofu model Have you looked and verified every authority in your CA file? Do you really trust the turkish government to be able to sign for any web site.

Aha! you say, this is why we have cert pinning.

To which my reply is. cert pinning is the tofu model where you have removed all user agency. it is better than the CA model but really sucks from a end user perspective. when thing go wrong, there is no easy way to fix it.

Re: The HTTP crash course nobody asked for

#126

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.

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

Re: The HTTP crash course nobody asked for

#127

Earlier quoted context omitted.

Your complaint is strictly social, and quite irrelevant here. Look, cleartext internet protocols are on the way out, because their model is fundamentally broken. For security reasons, I will note, and privacy. There, we joust security against security. Cleartext HTTP/1 is strictly a legacy matter, retained only because there’s still too much content stuck on it. But browsers will be more aggressively phasing it out s…

>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.

Re: The HTTP crash course nobody asked for

#128
post #123

Earlier quoted context omitted.

Your complaint is strictly social, and quite irrelevant here. Look, cleartext internet protocols are on the way out, because their model is fundamentally broken. For security reasons, I will note, and privacy. There, we joust security against security. Cleartext HTTP/1 is strictly a legacy matter, retained only because there’s still too much content stuck on it. But browsers will be more aggressively phasing it out s…

> If free issuance of certificates falters, the internet as we know it is in serious trouble. Deal with it. Social factors. This might conceivably happen, and if it does, HTTP/1 will not save you. This (HTTP/1 won't save us) doesn't seem entirely accurate to me. I can run free, untrusted HTTPS easily using self-issued certificates. It's relatively simple to think of mechanisms where trust can be layered on top of tha…

> I can run free, untrusted HTTPS easily using self-issued certificates.

At present you can. But think about what conditions might lead to free issuance faltering: it will almost certainly boil down to pressure from governments. And do you think that such governments will lightly allow you to bypass their measures? No; once the dust settles, no technical measures will be effective: the end result will be mandatory interception of all traffic, with TLS proxying and similar, and any other traffic blocked. Countries have even done this at times, requiring anyone who wants to access the internet to install their root certificate.

The internet is designed to be comparatively robust against sociopolitical attack, but if a sufficiently powerful government decides to concertedly attack the internet as we know it, the internet will not win the conflict.

> I don't know HTTP/3 at all, but if it is more tightly tied to CA infrastructure that is a problem.

As clarified elsewhere in this thread, HTTP/3 changes absolutely nothing about certificate verification; superkuh appears to have misunderstood the meaning of the text in the spec.

Re: The HTTP crash course nobody asked for

#129

Earlier quoted context omitted.

There is clear request framing in HTTP/1.1, it's mandated by keep-alive.

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.

Re: The HTTP crash course nobody asked for

#130

Earlier quoted context omitted.

HTTP/3 is written for the use case of large corporations and does not even allow for human persons to use it alone. It requires CA based TLS to set up a connection. So if you want to host a website visitable by a random person you've never communicated with before you have to get continued permission from an incorporated entity running a CA to do so. This is far more of a security problem than all of the bad HTTP 1.1…

Your complaint is strictly social, and quite irrelevant here. Look, cleartext internet protocols are on the way out, because their model is fundamentally broken. For security reasons, I will note, and privacy. There, we joust security against security. Cleartext HTTP/1 is strictly a legacy matter, retained only because there’s still too much content stuck on it. But browsers will be more aggressively phasing it out s…

[deleted]
Post reply on HN