As I understand it, (correct me if I'm wrong), https has two parts:
1. Encryption: protects from eavesdropping (e.g. your internet provider can't see what you're communicating)
2. Authentication: protects from MITM (e.g. someone changing the data en-route)
For full security you need both; but #2 is much more complicated than #1 because it needs a trusted third party, certificates, etc. It's effectively a barrier to having everyone use encryption.
Why isn't it possible to opt for only #1? It should be as simple as adding "Encrypt +All" to your apache settings.
You can't have protection from eavesdropping without protection from MITM, because MITM can be used for eavesdropping (as well as actually inserting malicious traffic into the communication.)
Which is why encryption without authentication is pointless (or, worse, illusory security) in most cases. On the internet, your communication is inherently being handed off through a number of intermediaries to an endpoint. If you don't know who the endpoint is, it doesn't do you any good to know that your connection is secure from you to the endpoint.
I agree and disagree. Not all adversaries have active intercept capabilities. Some are just passive. Defending against them isn't entirely pointless.
I really, really dislike the CA cabal. Self signed "encrypt only" certs combined with auto cert pinning in browsers would probably solve 99% of the problem.
What's a "just passive" adversary, other than a "potentially active adversary that chooses not to use the information they're collecting to leverage an active attack"?
Nobody likes the CA problem, but you can't handwave the problem away.
TACK (which provides auto-pinning) is hopefully going to be a solution to the lack of trustworthiness in CAs, but TACK's deployment model also presumes a CA infrastructure.
Well, more or less exactly what you said. An active attack is detectable, a passive one is not. There is no risk to me if I walk around with a wifi adapter in promiscuous mode just recording traffic. Actually doing a mitm exceeds my admittedly low risk tolerance.
Still, having #1 is still better than neither. Instead of the NSA (sorry for beating a dead horse) simply siphoning your plaintext off the wire, isn't it more secure if you force them to have to actively fudge every single key exchange in order to read your traffic?
The problem with this argument is that you don't need to be the NSA to compromise an unauthenticated encrypted channel; that's a task well within the capabilities of online criminals.
I'm didn't mean NSA specifically; that was just an example. I know it doesn't require massive hardware or anything like that because it doesn't involve breaking the encryption.
My original point is twofold:
First, having encrypted/unauthenticated communication is still better because it takes more effort to intercept, while doing so for unencrypted/unauthenticated is trivial (e.g. Google's WiFi sniffing debacle).
Second, encrypted/unauthenticated can be implemented to be almost completely transparent (for example, server and browser do a key exchange on every request; kind of how gzip compression is automatic), whereas encrypted/authenticated requires certificates (which you have to pay for, renew, copy on your server, etc.).
Right now X% of sites use HTTPS and (100 - X)% don't. It would be best if 100% of sites used HTTPS. But using _some_ form of encryption for the (100 - X)% is better than nothing, and more achievable than saying "encryption-only is useless, everyone should use authentication as well".
(I can't find any stats for HTTPS usage, hence the variables.)
I believe the problem is that it's impossible to distinguish between "the remote server doesn't care about authentication" and "the remote server cares about authentication, but your traffic to it is being intercepted and modified by an eavesdropper who is retransmitting the data without the authentication flag".
You can opt for only #1, but virtually every browser will put up gigantic warnings about it because it's indistinguishable from a MITM attack.
Right, but it's distinguishable from encrypted communication.
We have client-side signals for those things. http means unencrypted, https means encrypted. To do encrypted-but-not-authenticated, I guess you'd need a third URL scheme for it, to know when you're supposed to get that, since you can't shoehorn it into https safely.
1. Encryption: protects from eavesdropping (e.g. your internet provider can't see what you're communicating)
2. Authentication: protects from MITM (e.g. someone changing the data en-route)
For full security you need both; but #2 is much more complicated than #1 because it needs a trusted third party, certificates, etc. It's effectively a barrier to having everyone use encryption.
Why isn't it possible to opt for only #1? It should be as simple as adding "Encrypt +All" to your apache settings.