101–110 of 131 posts
HTTP 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…
HTTP 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…
Also restricts the ability of ISPs to inject ads into other people's sites.
I'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
ISPs and coffee shop wifi injecting ads into webpages wasn't a theoretical attack, but I'm more curious: Which barriers with HTTPS are you referring to?
Clock sync would be a requirement for access.
A recent device would be a requirement for access (not everyone can afford a new one).
Site admin keeping up with certificate registration would be a requirement.
Approval from the centralized certificate authority would be a requirement.
Server's self domain name matching accessed domain name would be a requirement.
These are all real scenarios where real people can be denied access to information that is crucial to them, up to the point of survival.
Just a few of the reasons why all my websites still allow HTTP.
HTTP is also way faster on slow connections.
I'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
ISPs and coffee shop wifi injecting ads into webpages wasn't a theoretical attack, but I'm more curious: Which barriers with HTTPS are you referring to?
Captive portals can and should have TLS enabled, even if they're internally served, there's nothing stopping you putting on a cert signed by a well known CA. The way I handle it is I have the captive portal DNS name in public DNS returning a private address. When I order the CA cert from my cert provisioner of choice, I'm able to pass all verification checks. I'd use LetsEncrypt if I could, but good luck getting that…
The problem is: If the first connection of the client is a https connection, your captive portal has no possibility to redirect this request to the portal.
HTTP 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…
My go-to HTTP-only endpoint is http://example.com . It should be usable for as long as IANA and the Internet as we know it exists.
Earlier quoted context omitted.
ISPs and coffee shop wifi injecting ads into webpages wasn't a theoretical attack, but I'm more curious: Which barriers with HTTPS are you referring to?
With how most of the internet already looks like without adblocker the difference would probably be impossible to even notice. Edit: Also around half the pages I currently have open are passing through cloudflare anyway and signed by them, so a third party hijacking the connection to throw in ads is just one business minded CEO away.
Cloudflare's customers aren't going to stand for that and will find a new CDN if it was ever shown to be the case that Cloudflare was intentionally altering content they're rehosting. Cloudflare's imperfect, but Prince isn't that dumb, so we're years away from even the hint of that being possible.
My go-to HTTP-only endpoint is http://example.com . It should be usable for as long as IANA and the Internet as we know it exists.
This was mine, too, until I started regularly using a (university) network where the local resolver resolved example.com to 127.0.0.1. I complained, and was told that RFC2606 gave them license to override it to anything they wanted, and that this behavior would not be changed. Doesn't square with my reading of the RFC, but complaining further wasn't going to achieve anything. Now I use neverssl.com.
A university I attended blocked all BitTorrent traffic at the protocol level. They theoretically allowed exceptions per their policy but when I applied for some bioinformatics images to be allowed they said they would only allow specific files for a 24 hour window. I applied for a file and got no response. I applied for 1000 files and got no response. Then I gave up.
Earlier quoted context omitted.
ISPs and coffee shop wifi injecting ads into webpages wasn't a theoretical attack, but I'm more curious: Which barriers with HTTPS are you referring to?
It's not theoretical, but it's also not the end of the world, and I would accept it if it meant accessing information that is important to me over not being able to access it at all.