On: Npm's Self-Signed Certificate is No More

[nevi-me]

Hasn't moxie discussed this a few years ago, that it's unsecure to send sensitive data from an HTTP page to an HTTPS one?

[IgorPartola → nevi-me]

The problem is simple: if you send me an HTML file over HTTP, an attacker can inject some JavaScript code that will catch the onsubmit event and also send the data elsewhere.

[nilved → IgorPartola]

That's a non-problem because people who care about online security don't have JavaScript enabled by default.

[IgorPartola → nilved]

OK what if the attacker replaces the action of the form to submit to their servers instead?

Also Pandora does not work without JavaScript just like most modern websites. Would be pointless to sign up then, wouldn't it.

Lastly, what you are saying is simply not true.

[barrkel → nilved]

Security isn't binary.

[nilved → barrkel]

Suffice to say: anybody who has JavaScript enabled by default demonstratably does not care about their security. Interest and competence in security is indeed a spectrum, but somebody in first grade math still knows what 2 + 2 is.

[leobelle → IgorPartola]

You'd be able to see that though, and you can actually load the form over HTTPS, just use https://pandora.com instead of http. It's stupid that it's not default though, and there is actually insecure content also loaded, so yeah. :(

[IgorPartola → leobelle]

Good. Perhaps I will sign up now. Last time I checked was almost a year ago. But yeah, that should be the default.

[jbinto → nevi-me]

The problem with this line of thinking is that if you take it to it's logical conclusion, you need to stop listening on port 80 altogether, and train users (or search engines) to only key in https:// URLs.

If you listen on port 80 and respond with a 301 Moved Permanently (pointing to the https:// URL), that can be MITM'd also. Just proxy to the real HTTPS site and rewrite all the links (using absolute protocols) to be HTTP. Or, if users are trained to look for the lock icon, proxy through an HTTPS server under your control with a convincing domain name.

Even if you do block port 80, it requires users be educated to never access the http:// version of the site, because a malicious network operator could just operate a forwarding proxy and rely on users hitting the http:// URL. After all, HTTP is the default protocol used when I type in www.website.url to access HTTP. (aside: Perhaps browsers should attempt HTTPS first and then fall back to HTTP?)

I don't know of any public websites that aren't vulnerable to this. It's currently too user-hostile to require https://, so everyone helpfully redirects.

The only saving grace is that most non-technical users today don't actually use URLs. They access Facebook by typing "facebook" into the Chrome URL bar. That's a secure search, which gives a secure link.

[icebraining → jbinto]

With HSTS, you're only vulnerable the first time you connect to a website; that's a massively reduced attack surface compared to being vulnerable each time you submit some form.