I usually use example.com for this purpose.
RIP HTTP
91–100 of 131 posts
Re: RIP HTTP
#92I'm still using HTTP and plan to continue for the next 25 years or so.[1] It is a highly accessible, highly compatible protocol, highly usable protocol. I also think the MITM risk is overrated compared to how much barrier HTTPS creates to accessing basic information. [1] https://en.wikipedia.org/wiki/Lindy_effect
Glorious nation of Kazakhstan agrees with you and up votes your comment.
Without https they could just mitm everyone without their knowledge.
https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_a...
Re: RIP HTTP
#93Earlier quoted context omitted.
> HTTP/1.1 pipeliing works better than ever > and a text-only browser. So you are saying http/1.1 pipelining works great if, checks notes , your use case is a text browser that probably doesn't download all the separate assets and thus wouldn't use (or just minimally use) pipelining anyways? So yes,i agree. Http/2 & 3 is pointless if your usecase is different enough from a normal person that all the usecases it is tr…
I just installed lynx the other day in an Alpine guest machine to pull down some source code. For the first time in years. Hearkened back to ancient days when the internet was less of a war zone. Whether this anecdote supports or refutes your point is an exercise for the reader. Alpine is righteous, though.
Unfortunately lynx, links and and w3m will only work on a subset of websites.
Re: RIP HTTP
#94Earlier quoted context omitted.
I've been using Caddy for personal projects and I don't even think about HTTPS anymore. Except when I have to use another web server at work :-/
That is fine for simple projects where all you have to do is automate cert updates for the root domain or a few subdomains. The problem is not to automate this process. It's easy to write a shellscript that regularly updates certs for a root domain or some subdomains. The problem is that letsencrypt does not offer url based authentification for wildcard certs. So you have to temper with your DNS infrastructure so tha…
Add to it that wildcard certificates are nice for not showing your sub-domains in certificate transparency logs.
Re: RIP HTTP
#95Earlier quoted context omitted.
Where can I go that has a bigger payload? When I've successfully opened a site on an unfamiliar WiFi network I'd like to know up front if I'm gonna have trouble loading stuff.
captive.apple.com is just for captive portals - technically networks can (and do) spoof it, but it's just a connectivity check. Past that you can do any test you want over https.
I'd rather have both in one :)
neverssl strikes a pretty good balance
Re: RIP HTTP
#96[deleted]
Re: RIP HTTP
#97Earlier quoted context omitted.
Or they just optimistically connect to both TCP/443 and UDP/443, create both a HTTP/1 and HTTP/3 connection in parallel, then see which one responds quicker. This already happens with some major apps.
Some might indeed do. According to my knowledge from testing 1 year ago it's mostly Safari that is doing this. Other browsers follow the specification and require Alt-Svc information.
I'm not sure the specification says what you describe, it doesn't in my reading.
I don't believe Alt-Svc is required, and as you say Safari is behaving this way already.
https://www.rfc-editor.org/rfc/rfc9114.html#section-3.1-3
Discovering an HTTP/3 Endpoint
A client MAY attempt access to a resource with an "https" URI by resolving the host identifier to an IP address, establishing a QUIC connection to that address on the indicated port (including validation of the server certificate as described above), and sending an HTTP/3 request message targeting the URI to the server over that secured connection. Unless some other mechanism is used to select HTTP/3, the token "h3" is used in the Application-Layer Protocol Negotiation (ALPN; see [RFC7301]) extension during the TLS handshake.
Connectivity problems (e.g., blocking UDP) can result in a failure to establish a QUIC connection; clients SHOULD attempt to use TCP-based versions of HTTP in this case.
Re: RIP HTTP
#98I'm still using HTTP and plan to continue for the next 25 years or so.[1] It is a highly accessible, highly compatible protocol, highly usable protocol. I also think the MITM risk is overrated compared to how much barrier HTTPS creates to accessing basic information. [1] https://en.wikipedia.org/wiki/Lindy_effect
Glorious nation of Kazakhstan agrees with you and up votes your comment. Without https they could just mitm everyone without their knowledge. https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_a...
That article is horribly named, and defames the national government. There is no proof and not even an assertion that Kazakhstan even attempted MITM attacks. There's just controversy about the certificate. There's not even an example of it being installed on user devices! What a tempest in a teapot. Yes, it had significant and devastating ramifications, but none of those came about, and Wikipedia should not be pretending that this is a bigger deal than it turned out to be. "Attack", my foot.
Re: RIP HTTP
#99HTTP encryption is a bit overrated. Governments only care about which sites you read and httpS don't help against that. TSL is also designed to be man-in-the-middle'd. Check your root certificates and ask yourself if you trust all those organizations. You will also likely find your ISP has a root certificate. The TLS handshake takes a lot of computer resources and makes your web experience slower. Encryption is good when you login to your bank over a random public wifi. It's unnecessary for public and open web sites that don't require username/password to login.
Re: RIP HTTP
#100HTTP encryption is a bit overrated. Governments only care about which sites you read and httpS don't help against that. TSL is also designed to be man-in-the-middle'd. Check your root certificates and ask yourself if you trust all those organizations. You will also likely find your ISP has a root certificate. The TLS handshake takes a lot of computer resources and makes your web experience slower. Encryption is good…
what's the status of DoH deployment and ESNI?