> Are you sure?

Yes, I'm sure that the communication between my browser and the test app I'm running on localhost doesn't need to be encrypted.

> It's obvious that governments are systematically weaponising any non-SSLd connections.

Over the public internet, sure.

OTOH, if a government controls a root CA trusted by your target population, TLS doesn't provide any protection at all against them anyway.

Yes, it absolutely does. If they actually use that CA to MITM connections, it is usually detected pretty quickly, and browsers quickly revoke that CA's trust.

Even in a scenario where this doesn't happen, it elevates the required attack from a passive eavesdropping attack (which is comparatively simple to conduct en masse, and to analyze data retroactively) to an active attack (which must typically be done in a targeted, real-time fashion).

> If they actually use that CA to MITM connections, it is usually detected pretty quickly

Really? How?

Certificate pinning [0] is a common way.

[0]: http://en.wikipedia.org/wiki/Transport_Layer_Security#Certif...

Right. Because no one ever changes a certificate legitimately.

Some people run TACK. Chrome also, IIRC, reports back on when certs have changed and Google can clearly see if there's widespread disagreement on what key is being served to visitors.

How is that going to help? If you've been MITMd then the attacker can intercept your TACK and Google traffic too.

Chrome pins the Google certs, so MITM will only work if you get the user before they've first downloaded Chrome. And then you have to ensure you only ever MITM those clients, or your attack will be detected.

And TACK literally was designed to solve this problem. If the MITM interferes with you communicating to other TACK clients, you detect their attack. If they don't, you detect their attack.

People may need to run embedded servers on many different devices, and be able to access them. Forcing them to use not the latest version of the browser simply because they can't use it to connect to a device that costs 100k and will not be replaced every year like your average iDevice will not make anything better or safer.

The issue was authentication, not encryption. Though SSL of course does both.

Authentication can be done much more cheaply than encryption (well assuming you have the clout to force a change in standards). It could be implemented as simply as <script src="baidu" hash="a84b3">. In particular such a request could be transparently cached without security concerns.

It seems like this would still have one of the issues SSL has where it's easy to get wrong and then it's no better than not having it, except that people think they're safe. E.g. use a weak hash function and someone can write a malicious script that hashes to the same value.

Yes, indeed, and I actually suggested this on the Mozilla thread.