Hacker News Reader

Comment by RexRollman | Hacker News Reader

Not everything needs to be encrypted. It's not that hard to grasp.

Are you sure?

Probably Baidu thought the same thing about their Javascript. It's a public file, so why use HTTPS? Then they got turned into the Great Cannon and now they're being described as a weapon of the PRC in major newspapers.

It's obvious that governments are systematically weaponising any non-SSLd connections. If you don't use SSL, you're making it easier for them to hack your users and turn your website into a weapon. If you wouldn't let botnets run wild on your servers, you should take the same care to encrypt your website.

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.

> 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.

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.

Yes it does. For the umpteenth time, an unencrypted HTTP session allows an attacker to inject arbitrary content into the request/response stream. They can use this to do anything, from asking you to log in, sending them the password, to stealing credit card numbers, to presenting fraudulent content, to giving false information, to tracking you, to hijacking links from the page you are trying to view, to just showing you ads where there should be none, to defrauding the site/domain owner (via serving bogus content instead of your own).

And a MITM'd captive portal can do the same over SSL against users who don't understand the gravity of whatever warning their browser shows. For HTTPS to be everywhere, there needs to be zero reliance on certifying authorities that your uncle and grandmother have never heard of, zero dialogs/UI indicators that they'll just learn to ignore anyway, and zero effort to maintain the server-side of it.

It's a much bigger challenge, and I find it wildly cavalier for anyone to say "just use HTTPS everywhere" without directly addressing the faults pointed out by others. And by addressing, I don't mean dismissing out of hand.

Hell, I'd settle for acknowledging instead of addressing some days. There are real world problems on both sides that need to be considered.

I am acknowledging that there are issues with the CA system, and elsewhere have proposed plans for how to eliminate them from our trust chains (tldr: registrars issue you a CA that's only good for the domain you bought from them; then you are your own min-CA).

But these are two separate issues. Going from plain HTTP and HTTPS to HTTPS-only is a step in the right direction. It's also step 1. Step 2 is to drop CA's and work out a better trust system that relies on less parties being involved.

Also, let's give people some credit. Yes, some people ignore the self-signed cert warning. Some people also respond to Nigerian prince emails. We aren't talking about cutting off email because someone might get hurt. Unless you are ready to drop all untrusted certs, those dialogs need to stay in place.

Reply on news.ycombinator.com