So even given the mass surveillance problems, non-https connections need to start being treated as Bad Practice and discouraged by the sysadmin community.
1. Unencrypted (for casual/ad-hoc web servers serving cache-able static assets)
2. Encrypted-untrusted (for casual/ad-hoc web servers that just want to thwart basic Wi-Fi cookie sniffing)
3. Encrypted-trusted (for most established websites)
Right now, #2 isn't a viable option, because HTTPS servers with self-signed certificates are correctly treated as dangerous. A URL that designates the HTTPS protocol must always require a trusted connection.
The solution is (relatively) simple: HTTP 2.0 should allow encrypted-untrusted connections for URLs designated with the HTTP protocol.
Encrypted-untrusted prevents mass passive surveillance, and requires it to be active MITM. And - as I've pointed out on the TLS WG list a few times - if an attacker can't tell you're being opportunistic, they might not be willing to risk being detected. We can make them take that risk by reducing the visible distinguishers there.
My question is given that what is the purpose of encrypted-untrusted? It's no more secure than HTTP for anything that uses session cookies or the like. Sure the connection is encrypted, but then all you are doing is stopping people seeing that you are accessing My Little Pony shows on YouTube. If it's a public hotspot at the coffee shop, they can probably see you watching it (IRL) anyway. Given the connection is untrusted, it wouldn't be hard for the NSA to do a MITM attack at the ISP level.
For what it's worth, YouTube does use HTTPS for My Little Pony shows. Actually, there's a hidden service on Tor for that. (I'm not even joking.)
Going forward hopefully TLS 1.3 or a later version will be able to encrypt enough of the exchange that a passive sniffer can't necessarily tell between 2 or 3 - hopefully they won't be able to see the certificate, or there'll be a way to negotiate an anonymous DH as a minimum that an attacker cannot observe (without that in place right now, I've argued against aDH remaining in TLS 1.3).
That's just one example, of course. There are countless others.
#3 can't be spun up on an ad-hoc basis. It requires a domain name and a signed certificate. This costs time and/or money, and simply isn't feasible for the smallest websites.
#2 can allow the most simple web server instance created in five minutes to be guarded against passive snooping by governments and hackers.
The next step up from that would be unsigned public keys with pinning (like ssh) to reduce MITM, and finally above that would be identity verification on the level of https.
That is a common misconception. If I MITM when you establish connection, how would you notice? My self-signed certificate looks like a real one.
That's why we need CAs (or WoT, or whatever), to verify identity after we've established a secure channel.
How? An encrypted connection subject to MITM is as secure as an non-encrypted one. Attackers will stop listening for plaintext credentials at WiFi spots and will just launch their favorite HTTPS MITM tool instead.
Certificate pinning is flawed because you cannot revoke certificates from your clients. How would you distinguish a MITM attack from a certificate change? And if you can't revoke certificates, what happens after an attacker gains access to the private keys? Definitely flawed model.
HTTPS without identity verification is even worse than HTTP. IMHO a false sense of security is more dangerous than no security. Self-signed certificates must not be advertised as secure by browsers (the famous lock icon) because they are not! This would render them invisible for most users.
Self-signed certificates are only viable for tech-savvy users, and even then the dangers are too many and the burden too heavy (did the server change certs, or am I being subject to a MITM attack?) for them to be useful.
1. Opportunistic encryption without certificates or identity pinning -- protects against dragnet surveillance and packet sniffing, but not MITM.
2. Encryption with pinned self-signed certs -- protects against second connection MITM, but not stolen certs without some revocation design.
3. Encryption and identity verification with CA- or WoT-signed certs -- protects against first connection MITM except by powerful adversaries.
Best solution? Not by a long shot, but it is a reasonably simple one to implement and does improve things.
It would not be acceptable to trade the ability to change SSL keys for a trust-on-first-use model. There are solutions to this of course, but also tradeoffs. These needs to be taken into account.
The CA idea is broken but not too easy to replace. http://convergence.io/ could be a few steps forward.
This is what we tell users to do today for important sites, and not click in links in mail or elsewhere. It is not obvious that there is a net benefit in security.
Well, you decide whether you want to trust the person on the certificate, and if the security ever changes again that'd be the red flag. Initial trust is always difficult.
https://tools.ietf.org/html/rfc6698
What, your domain doesn't have DNSSEC because your registrar doesn't offer it? It'll have to have the opportunity to next year, if they want to renew their contract with ICANN...
- Any time a certificate could be impersonated by an attacker, the attacker is also able to block a revocation check.
- Live revocation checks (A) kill performance, and (B) leak information as a side-channel.
- You could solve this by predownloading every single revocation ever. But that is massive (infeasible for mobile), never going to be up to date, and leaks information about private domains.
See Adam Langley's blog for more about OCSP vs CRLsets.
I have used cheapssl.com (now ssls.com) for a number of years, probably a total of 20 sites, without a single issue.
That being said, namecheap or gandi.net also both offer reasonable priced certs.
Just so you are aware, if you think the $1,000,000 insurance policy offered with the more expensive providers is worth _anything_, be sure to read the fine print first.
The only potential more expensive thing of value is buying an EV cert to get the green URL bar - not that it actually provides even a little bit more protection, it doesn't - but because users see them and have been conditioned to immediately associate it with trust.
A good example of this is reddit, that is not https for logged in users with write ability (and thus PostgreSQL write ability). If you have malware that sniffs public wifi traffic for reddit session cookies, you can easily start to test all those write calls for exploits.
[1] - http://www.nytimes.com/2014/08/06/technology/russian-gang-sa...
Perhaps not, but consider for example that the Starbucks near people with valuable IP (e.g., many Starbucks in Silicon Valley, in NYC, in Washington DC, in Redmond WA, in Cambridge MA, in Beverly Hills, in the Hamptons, etc.) would be valuable targets.
And in general it's probably not a good idea to set world-wide standards on the most used high level protocol in the world based on a few rich people who use the net from an unsecure device.
Yes there are other vulnerabilities, but that's not a reason to fail protect against this one (taking that reasoning to an extreme, all security is pointless because there always are other vulnerabilities). The purpose of security is to increase the cost of a successful attack; https has a high ROI in many cases. In the example you give, spear-phishing is much more expensive than sniffing wifi.
Really, TLS should just be a mandatory part of the protocol. I haven't read any convincing reason why it isn't, other than vague hand-waving, eg, "we're just a standards body and can't enforce policy".
The 1% of sites it does matter for are things like banks and the like, where you need to hammer into users heads that certificates should be valid via other means.
Of course, it's casually accepted that it's a-ok for companies to MitM their employees encrypted connections anyway, so I don't really know where that leaves us.
This is why the SMTPS port is being resurrected, and STARTTLS-type upgrades are not considered good practice in future - port assignments in future are likely to take that into account.