91–100 of 148 posts
That was a good extension for a specific time. I stopped using it about 5 years ago when everyone had been pushing HTTPS hard, and Let's Encrypt had become popular. I didn't notice any websites not using HTTPS, so I didn't look back.
http://neverssl.com remains for those badly-setup wifi networks.
Earlier quoted context omitted.
http://neverssl.com remains for those badly-setup wifi networks.
Similar to HTTPS-only being built into web browsers, isn't captive portal detection built into all modern OSes? What's the badly-setup wifi network that requires you to open your browser but doesn't get detected properly by the OS as a captive portal?
Earlier quoted context omitted.
http://neverssl.com remains for those badly-setup wifi networks.
It's funny that if I navigate to this site with HTTPS-only mode, it redirects to an HTTPS page.
Earlier quoted context omitted.
The article talks about how to get this HTTPS by default functionality in all major browsers. I don't see how your complaint about not being redirected to HTTPS is relevant with those settings enabled.
There's still plenty of useful websites that are HTTP-only or that have HTTPS misconfigured. The HTTPS-only mode will break them, whereas HTTPS Everywhere just works.
Earlier quoted context omitted.
There's still plenty of useful websites that are HTTP-only or that have HTTPS misconfigured. The HTTPS-only mode will break them, whereas HTTPS Everywhere just works.
+1. I was having this sort of issue setting up an Android tablet as a wifi CNC pendant. The controller is based on an ESP32 (which has limited storage for a full cert chain) and I run it without a gateway address on it's own VLAN. I'm certain it's "secure enough". Turns out Android + Firefox mobile keeps trying to turn "http" to "https" and at the same time specifying the IP + port explicitly in the URL is considered…
Firefox isn't just assuming all ports are prohibited, it has a relatively short list of ports where we know it's crazy to pick HTTP on those ports and sometimes people do it to exploit protocol parsing issues, so it forbids that.
Earlier quoted context omitted.
> Where did uMatrix come from? But is uMatrix to trust? Can you trust uMatrix developers? I have bought a pair of shoes from an HTTPS only web sites, shoes never arrived, HTTPS apparently can't fix everything. Trusting trust is a problem since computing was invented. [1] [1] WARNING! PDF! https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
Without some kind of baseline for secure connections you can't even start approaching the problem of trusting trust. Yes, it's hard to figure out whether or not to trust uMatrix. But I'd rather not make that even harder by allowing basically anyone to intercept and modify the code that uMatrix is sending at any time.
Even if SMS are "easy" to intercept, even if I send you an email with the SHA256, using a side channel greatly improve security, unless you're being targeted on multiple channels, which is quite uncommon.
For the same reason, even an MD5 hash is good enough most of the times. Even if it's been proven not secure years ago, it's secure enough to trust that in the general case the odds of generating the same hash while also creating something that is not simply broken, but it's malicious, are very, very low and require effort.
the point is: HTTPS still relies on trusting things we can't control and we will probably never control.
We are forced to trust HTTPS because there is nothing more we can do.
> But I'd rather not make that even harder by allowing basically anyone to intercept and modify the code that uMatrix is sending at any time.
But the reality is that it is hardly "everyone"
a MITM must be, by definition, in the middle.
Debian survived for decades delivering their packages over HTTP
Earlier quoted context omitted.
Right, but that's not HTTPS Everywhere. HTTPS Everywhere was "this site already has HTTPS, and really should only use that, but doesn't, so we'll redirect you to the HTTPS version". Now sites that have HTTPS default to it, and browsers have options to basically try https first and see if it works.
Should have been called "HTTPS as long as its already there". "HTTPS Everywhere" is pretty suggestive. And the English meaning of the words might be a worthwhile goal too.
Earlier quoted context omitted.
A permanent redirection before setting the correct headers is the best you can do at the server side. Yes, the user is using insecure practices, and no, you can't correct it on your server.
I am arguing that the best you can do is not even have HTTP enabled. A permanent redirect is the second best ;) And yeah, most practical for commercial entities (which is why I highlighted what I do for my personal sites).
You not serving http won't prevent a MITM from serving http to the victim.