GET / HTTP/1.0\r\n\r\n
Still works with many websites.The HTTP crash course nobody asked for
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.
Chunked transfer/content encoding problems still give me nightmares...
Re: The HTTP crash course nobody asked for
#123Earlier 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…
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
#124Earlier 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): *…
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
#125Earlier 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.
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
#126Earlier 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.
Re: The HTTP crash course nobody asked for
#127Earlier 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…
Re: The HTTP crash course nobody asked for
#128Earlier 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…
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
#129Earlier 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…
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
#130Earlier 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…