5 ms·

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

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.

unethical_ban 12y ago
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.
- teraflop 12y ago
  What part of this proposal made it seem like static sites with non-critical info would be "crippled" over HTTP?
  - to3m 12y ago
    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.
- nitrogen 12y ago
  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.
  - nfoz 12y ago
    How does that go away? Most internet advertising/surveillance is performed by the actor with whom you're directly communicating, I think....
- Teapot 12y ago
  Regardless how static a site is attackers are free to inject any script code they wish in the HTML page on Http.
joshmn 12y ago
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.
- opejn 12y ago
  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.
- icebraining 12y ago
  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.
- NeutronBoy 12y ago
  > 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.
tyho 12y ago
What features have to do with encryption is this. If a browser asks a user "Do you want http://example.com http://example.com to be able to access your camera", what it is really asking is "Do you want http://example.com 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.
- bashinator 12y ago
  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.
  - tyho 12y ago
    And perhaps most importantly of all, your employer/school.
    - walterbell 12y ago
      Who can intercept SSL traffic.
      - icebraining 12y ago
        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).
        xxs 12y ago
        If they require proxy and root cert installation. They can do whatever they please.
      - sfilipov 12y ago
        Only if you use their device instead of yours.
teraflop 12y ago
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.
ikeboy 12y ago
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?
finnn 12y ago
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"
beeworker 12y ago
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...
- teraflop 12y ago
  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.
  - beeworker 12y ago
    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.
  - sfilipov 12y ago

unethical_ban 12y ago

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.

teraflop 12y ago
What part of this proposal made it seem like static sites with non-critical info would be "crippled" over HTTP?
- to3m 12y ago
  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.
nitrogen 12y ago
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.
- nfoz 12y ago
  How does that go away? Most internet advertising/surveillance is performed by the actor with whom you're directly communicating, I think....
Teapot 12y ago
Regardless how static a site is attackers are free to inject any script code they wish in the HTML page on Http.

joshmn 12y ago

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.

opejn 12y ago
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.
icebraining 12y ago
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.
NeutronBoy 12y ago
> 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.

tyho 12y ago

What features have to do with encryption is this. If a browser asks a user "Do you want http://example.com http://example.com to be able to access your camera", what it is really asking is "Do you want http://example.com 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.

bashinator 12y ago
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.
- tyho 12y ago
  And perhaps most importantly of all, your employer/school.
  - walterbell 12y ago
    Who can intercept SSL traffic.
    - icebraining 12y ago
      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).
      - xxs 12y ago
        If they require proxy and root cert installation. They can do whatever they please.
    - sfilipov 12y ago
      Only if you use their device instead of yours.

teraflop 12y ago

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.

ikeboy 12y ago

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?

finnn 12y ago

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"

beeworker 12y ago

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

teraflop 12y ago
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.
- beeworker 12y ago
  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.
- sfilipov 12y ago