The problem with this argument is that there are very high-security pages on the Internet --- things that protect people's bank accounts or most sensitive personal information --- and they're not going away. The junction, at the protocol level, between insecure web sites and secure ones is a major design weakness; we would have fewer attack vectors in the long run if we could count on uniform encryption across the web.
This is precisely my thought on SSL. I'm no expert (correct me if I'm wrong), but if I understand the technology correctly: if your http website connects to an https login page, who is to stop someone from spoofing a link to a fake login page on the http website.
This is an annoying problem – even if your entire site uses HTTPS, users could be vulnerable if they ever follow an HTTP link or their browser's autocomplete doesn't update to use HTTPS.
Strict Transport Security was designed to solve that problem partially by telling the browser to never make an insecure HTTP request:
That's widely supported now but it does require your browser to have previously visited the legitimate site within the stored `max-age` period. Preloading (https://hstspreload.appspot.com/) can close that further but increases the organizational commitment that your web developers will never break the all-HTTPS contract by mistake.
EV certificates may improve a user's awareness of a spoofed page, but cannot do anything to make it more technically difficult to execute.
Providing an HTTPS login with an otherwise HTTP site is vulnerable to redirection to HTTP or to another site.
There is lots of evidence that suggests that in this configuration, cookies are often not set up properly (secure only) and can therefore be transmitted and stolen over HTTP.
Totally agree, encryption by default is the best option. However:
And if SSL is offered perhaps it should still be possible to access non-security-critical pages by plain old HTTP.
I often thought about setting up a forwarding proxy for my sites that listens on `un{encrypted,secure}.mydomain.tld` and provides plain old, non-optimized and unencrypted HTTP/1.1 access for those who wish to access the sites that way. I've experienced the issue with slow loading times when roaming (bandwidth is expensive) and/or in remote areas (very low bandwidth and spotty coverage) a couple of times, and having low-profile variants for browsing essential stuff would've helped a lot.
However, I'm not sure if this will open attack vectors for the unencrypted sites. I.e. I'd imagine that a man-in-the-middle-style attack could show the main site / URL (www.mydomain.tld) with another cert and just forward the un{encrypted,secure} content … but then again, this is not a new technique and can be prevented by public key pinning (though, https://news.ycombinator.com/item?id=12434585 :-/), DNSSEC/DANE (no browser vendor buy-in yet), etc.
Any idea if this were a sane idea for other sites as well? With enough momentum, browser vendors could detect and display un{encrypted,unsecure}. sub-domains specially.
