Hacker News Reader

Comment by UnoriginalGuy | Hacker News Reader

I agree with trying to phase out HTTP, but I think their method is "annoying." What do features have to do with HTTP Vs. HTTPS? It just seems like an arbitrary punishment.

Wouldn't it just be significantly easier to simply change the URL art style to make clear that HTTP is "insecure." Like a red broken padlock on every HTTP page?

That has the following advantages:

- HTTP remains fully working for internal/development/localhost/appliance usage (no broken features).

- Users are reminded that HTTP is not secure.

- Webmasters are "embarrassed" into upgrading to HTTPS.

- Fully backwards compatible.

Seems like a perfect solution where everyone wins.

View on HN

What features have to do with encryption is this. If a browser asks a user "Do you want http://example.com to be able to access your camera", what it is really asking is "Do you want http://example.com, anybody on your local network, state actors, anybody between you and example.com, people who can mess around with BGP and your DNS provider to be able to access your camera?". TLS mostly makes the first question more truthful.

You might explicitly include "employees of the coffee shop/hotel/library providing wifi" in the list of actors who can intercept your traffic. Honestly, I think that one will get the most attention of the average person.

And perhaps most importantly of all, your employer/school.

Who can intercept SSL traffic.

Only if they also control the PC or you allow them to install certificates. You can still safely use their network with your own device(s).

If they require proxy and root cert installation. They can do whatever they please.

Only if you use their device instead of yours.

It sounds like this is mostly going to be focused on features that require user consent. The article gives the example of media devices (camera and microphone) but there are plenty of others: fullscreen API, geolocation, notifications, large amounts of offline storage, etc.

These capabilities are sensitive enough that you want to give users control over who is granted access. But if pages are being loaded over HTTP, the user can have no way of establishing the authenticity of the Javascript code they're granting permissions to.

I can imagine a lot of personal sites will suffer from this. With most, they're sitting on something like Eleven2 or Dreamhost, who requires a dedicated IP for an SSL certificate, which the user then has to buy and figure out for himself (it's not trivial for the average "webmaster"), or buy the certificate from their host which is marked-up plenty.

Yes, the hosts could wildcard. Yes, there are other solutions out there. But for the average Joe who is blogging about his vacations and family? They're going to be completely lost.

Why don't shared hosts just wildcard? Shared certificate? Well, let's think about it... Charging ~$5/month/dedicated IP is a nice upsell, and getting $70 for an installed SSL cert that costs them $10 from their SSL cert reseller, that takes them 2 minutes to configure... That's a nice slice of pie. I'd take that bet any day.

I think you're overstating how bad things are. Dreamhost, for example, no longer requires a dedicated IP for SSL, though they do still recommend it for e-commerce. They are charging $15/year for a CA-signed certificate. Granted, that's for a single-site cert and they don't support wildcards under this scenario, but the vacation blogger isn't likely to need that anyway.

Charging ~$5/month/dedicated IP is a nice upsell

It's only an upsell now. If in the future SSL is required to get access, it stops being an upsell and starts having to be part of the basic package. Whether that will raise prices significantly is yet to be seen.

> But for the average Joe who is blogging about his vacations and family? They're going to be completely lost.

Average Joe uses Facebook, Tumblr, Wordpress, or any number of existing hosts to blog to his family.

The actions Mozilla proposes sound awful. I believe that a secure (from the NSA) Internet is the way forward. But this seems so goofy to me. There are legitimate reasons for a site not to be hosted on HTTPS.

  * It is a static site with no forms or logins  
  * It is non-critical info  
  * The site operator can't afford a certificate (Let's Encrypt is only one site...)

As you say: Color-code sites with a bit more granularity. Don't cripple the cleartext web.

What part of this proposal made it seem like static sites with non-critical info would be "crippled" over HTTP?

Static sites or non-critical info! "Gradually phasing out access to browser features for non-secure websites, especially features that pose risks to users’ security and privacy" could affect sites that don't expose critical info.

All browsing behavior can be used to build a profile about someone, whether for advertising, surveillance, or whatever. There's a lot more information in the fact that person A visited pages 1-6 on unencrypted website B than one might realize. This reason alone should be enough for us to demand encryption (not necessarily via CA certificates) for any connection that isn't demonstrably local and unintercepted.

How does that go away? Most internet advertising/surveillance is performed by the actor with whom you're directly communicating, I think....

Regardless how static a site is attackers are free to inject any script code they wish in the HTML page on Http.

I was thinking that was the way to go too for a while, but then I realized that marking http as insecure will just get user used to clicking through security warnings and assuming that they're "normal"

While we're making art style changes, why don't we change the experience for self-signed certs?

When the user first visits an HTTPS page with a self-signed cert, they get the content, and the URL art style has a broken lock or something warning it's not known to be secure. (It's better than raw HTTP but it's not trusted.) With certificate pinning by the browser, the next time the user visits that page, if it's different, then they get the current experience that warns them in big scary text and requires several clicks to get past. There's a question of if it's different in that the server owner upgraded to a paid SSL cert should it show a warning or not, but if there's a way to sign that upgrade with the old cert that the browser can know about there shouldn't be a problem...

So if I have to renew my (self-signed) certificate, all my current users will now get scary warnings? I'm not sure we should be encouraging people to hold on to their possibly-compromised certs.

> When the user first visits an HTTPS page with a self-signed cert, they get the content, and the URL art style has a broken lock or something warning it's not known to be secure.

Do we assume the user is going to notice that URL art style, and actually heed it? Because if the answer is "no" (and I think in reality, the answer would be "no"), then pick a high value site, and MitM it with a self-signed cert. The user misses the indicator, and proceeds to interact with the site; does JS work? (let's steal the user's cookies) do forms work? (please log in!)

If you have the ability to MitM a high value site like facebook.com without getting caught, I think it's worthwhile to do so regardless simply because you'll get some portion of the users who bypass the warning. In my scheme, the only people who won't see the warning are those who have never visited facebook with that browser before, so they may or may not have an account to login with that you can hijack.

Not a bad idea, in theory, but... suppose I visit a site on Monday and see certificate A. Then when I return on Tuesday, I see a different certificate B. What reason is there to think that A is likely to be the "true" certificate, and B isn't?

Showing a big scary warning in one case, and not in the user, implies to the user that the browser has some reason to think one is more secure, which is misleading.

You could use some website which you connect to securely (CA signed) which fetches and displays fingerprint C. You can then compare it to A and B and the one which matches C is the "true" one.

Of course the whole thing can be automated by the browser and happen behind the scene - i.e. Firefox connecting to a Mozilla service for each self signed website it sees and comparing the fingerprints. Then it can store information about this self-signed certificate as trusted.

That sounds essentially the same as how Let's Encrypt works: https://letsencrypt.org/howitworks/technology/

Except that rather than creating a self-signed certificate and then asking an external service to store a fingerprint, you just let the external service sign your certificate.

EDIT: Oh yeah, and signing the certificate up-front has the nice benefit of not forcing browsers to leak private information (namely, the domain names that are being accessed) to a centralized third party.

I agree in that scenario it's hard to say whether one is more likely to be the true certificate than the other. If we're assuming attacks that aren't targeted towards specific users (e.g. from state actors, or just a corrupt hotel wifi admin, who are attacking whoever happens to be on the network) then we can't say without more details about the network you were connected to on Monday vs. Tuesday. If we're assuming attacks that are targeting you specifically as an individual, perhaps A could be considered slightly more likely than B due to coming first... Visiting the site on Monday leaks the information that you visited the site, so an attacker may believe you will visit that site again. But if the attacker is keeping logs of your traffic habits, they may have just chosen Monday to poison your fresh DNS lookups. So again it looks like we can't say which is more likely.

Allowing some things on http can be a security risk. If you store a cookie, how do I know it's going to the same site next time?

Reply on news.ycombinator.com