8 ms·

As somebody on the dev build train normally I've seen this change for quite a while now and my brain quickly stopped processing the warning on HTTP only sites.

by pilif 8y ago

As somebody on the dev build train normally I've seen this change for quite a while now and my brain quickly stopped processing the warning on HTTP only sites. I hope that flipping the switch now will cause enough of the remaining non-https sites to start looking into switching before Chrome feels the need to start adding "more prominent" warnings (for example using a modal dialog). I agree that, yes, in general, we should all be using HTTPS on the internet, but non-secured HTTP still makes sense for example during development or for home routers and printers where traffic encryption is less important compared to the initial UX (my parents could probably set up a home router on their own if it's using non-encrypted HTTP but they would be totally unable to proceed if it's using a self-signed cert).

nodesocket 8y ago
I think one solution would be to make the secure badge more prominent, thus when insecure your eye would be attracted to it. One solution would to be make the entire background color of the secure badge green and invert "Secure" text white.
- lozenge 8y ago
  That's basically the approach taken so far and it hasn't worked. Users don't notice these decorations. Chrome wants to move away from the "Secure" wording because people don't understand what it means, for example, they think it means they can trust the site not to misuse their credit card details.
  - danieldk 8y ago
    Well, it doesn't help that the text (when clicking on 'Secure') says: Your information (for example, passwords and credit card numbers) is private when it is sent to this site. To the layman this means: Chrome says it is safe to enter credentials on this site (and not that it just means that it is hard to eavesdrop on the connection), especially that because this does not say anything about the trustworthiness of the site.
    - nsgi 8y ago
      How would you phrase it instead, that would communicate the nuances of the issue and allow the lay user to assess the risk?
- anabala 8y ago
  People are quickly getting 'warning' fatigue. Endless popups on websites warning them about cookies?! Asking them to accept stupid privacy policies, alerting them to gdpr rules. The internet is fast becoming unusable because of all this utter nonsense.
- OskarS 8y ago
  I think it should be more prominent than that: make it the size and style of the "do you want to accept notifications?" dialog. It should be unmissable by users that they're on an insecure site.
  - Jaruzel 8y ago
    ... only if it did it for non private IP ranges. Otherwise all your home stuff would constantly be throwing up notifications.
angrygoat 8y ago
I don't think it's really about what end-users do with the warning, or whether they tune it out; site owners will not want a big "Not Secure" badge showing next to their page, right next to their domain / brand. This change creates a powerful incentive for sites to move over to HTTPS.
xg15 8y ago
> non-secured HTTP still makes sense for example during development or for home routers and printers where traffic encryption is less important compared to the initial UX I think this goes deeper. Currently, supporting HTTPS means you have to have some kind of internet connection, back-end infrastructure and other running costs. Even if you use Let's Encrypt and DNS validation, you will have running costs to keep the domain name registered and you will need some way to periodically transfer new certificates to your devices. Even if you somehow manage to update the device without a permanent internet connection, if someone wants to access the web interface, they will have to use the domain name - and therefore at least need to be connected to an internet DNS server so the domain resolves. So if, at some point, browsers would completely drop support for HTTP, this would suddenly force any kind of device with a web interface into an IoT-style lifecycle where the device loses functionality once its vendor is not able to support it anymore - even if the vendor would want people to continue using the device and even if there is no technical reason for it.
- tialaramex 8y ago
  Devices don't _have_ to prevent you from choosing their name. If I name the device my-funky-hatstand.tialaramex.example, then even if the Funky Hatstand company goes out of business and their domain name goes away, I can renew my certs, for my name. For a $5 product it may not make sense to have this level of configuration, but for example I believe the FireBrick (a device you might buy to put a small company or district office online) is capable of being configured with your name rather than a generic product DNS name that could go away. Also, just because a name is in DNS doesn't mean you must use the Internet to resolve the name. In a truly offline system you can just hard code that name resolution and it'll work fine. Nothing about HTTPS cares how resolution was actually done, only the BRs for the Certificate Authorities tell them they mustn't issue for names that aren't actually part of the public DNS hierarchy. So, the device needn't be on the Internet. The name must make sense in the Internet DNS hierarchy, but (with a typical commercial CA) needn't actually exist or (with Let's Encrypt, who insist on checking) needn't resolve to anything, let alone an actual machine on the Internet Yes, you will need to move new certs to a device if you want it to remain publicly trusted as time passes. If that's an unacceptable burden (maybe your device is under the North Pole ice) then you probably didn't want the Web PKI, you need your own PKI for your very special application. Most people want the Web PKI.
MaxBarraclough 8y ago
Agreed. I'm sure Google will take that into account if they decide to ramp-up the prominence of the 'warning'. As it is, the warning seems to be disabled for localhost/127.0.0.1 (where I only see a 'not secure' if I manually click the ⓘ) but the warning shows as usual if I browse a local IP address over plaintext HTTP.
vicbun 8y ago
> non-secured HTTP still makes sense for example during development To make it easier & cleaner in development, it's best to make yourself a Certificate Authority CA and issues local certificates. This makes for no warnings in browsers and ensures a better development experience. A post from my colleague on how to do it https://reactpaths.com/how-to-get-https-working-in-localhost-development-environment-f17de34af046 https://reactpaths.com/how-to-get-https-working-in-localhost...
- pilif 8y ago
  > To make it easier & cleaner in development, it's best to make yourself a Certificate Authority CA and issues local certificates sure. That's what I do on those sites where I absolutely need SSL even during development. But it's still a hassle and, I would argue, an overall security downgrade. If somehow that CA certificate gets out (commited to github by accident, extracted via malware, etc.), I become MitMable unless I manually check every certificate of every site I visit. I know that this isn't too likely an attack vector, but if I had to target a developer friend, that's something I'd look into because this has the potential to work across machines whereas traditional malware based solutions would only work on machines I can compromise. If you have unique CAs per development machine, this would of course be moot, but at that point, you might as well just run with a self-signed cert to begin with and allow the exception once.
  - tialaramex 8y ago
    Certificates are public documents, it isn't a problem if everybody sees them. Committing the certificate is, at worst, a minor inconvenience for someone who doesn't want your certificate because they don't trust your CA. A _Private Key_ is the thing that needs to be kept private, in Microsoft Windows it's common to bundle this together with a corresponding Certificate in a single file, often with the filename extension .PFX I assume it's more "convenient" this way, shame about the security. If you do this a LOT (maybe you're a team of fifty developers at a software company that mostly builds web apps but has a strict policy of not using "real" certificates or wildcards) you should mimic the hierarchy required of "real" public Certificate Authorities: Mint a "root CA". You'll end up with a certificate and a private key, let's call them root-C and root-P. Every developer (and QA and so on) system needs to trust root-C, you can use Group Policy or similar tools to arrange that. Use the root CA to issue a sub-CA, the "issuing CA". Write _constraints_ in the certificate used to issue this sub-CA. A constraint is a rule about what things the Subject is an authority about in the opinion of the Issuer. So for example if you set a DNS constraint of just example.com, certs for example.org, or google.com from this Issuing CA don't work. If you later acquire example.org, you can "just" replace the Issuing CA. No updates to employee systems. Think about the Constraints you write, so that they block "mistakes" like MITMing google.com, but not anything you expect to actually need. You can also constrain the types of certs issued. Will you only issue TLS server certs? Then write a constraint saying so. Now, lock away root-P, a serious CA has it in a special hardware device to protect it, but a USB key in a locked desk drawer is a good first step. The Issuing CA credentials will probably need to stay live on someone's computer, they're valuable of course, but because of the Constraints they now aren't an unlimited black hole in your security.
epanchin 8y ago
Did they remove the “Secure” label too? Doesn’t say in the blog post.
- Vinnl 8y ago
  No, that will happen later.

by pilif 8y ago

nodesocket 8y ago

I think one solution would be to make the secure badge more prominent, thus when insecure your eye would be attracted to it. One solution would to be make the entire background color of the secure badge green and invert "Secure" text white.

lozenge 8y ago
That's basically the approach taken so far and it hasn't worked. Users don't notice these decorations. Chrome wants to move away from the "Secure" wording because people don't understand what it means, for example, they think it means they can trust the site not to misuse their credit card details.
- danieldk 8y ago
  Well, it doesn't help that the text (when clicking on 'Secure') says: Your information (for example, passwords and credit card numbers) is private when it is sent to this site. To the layman this means: Chrome says it is safe to enter credentials on this site (and not that it just means that it is hard to eavesdrop on the connection), especially that because this does not say anything about the trustworthiness of the site.
  - nsgi 8y ago
    How would you phrase it instead, that would communicate the nuances of the issue and allow the lay user to assess the risk?
anabala 8y ago
People are quickly getting 'warning' fatigue. Endless popups on websites warning them about cookies?! Asking them to accept stupid privacy policies, alerting them to gdpr rules. The internet is fast becoming unusable because of all this utter nonsense.
OskarS 8y ago
I think it should be more prominent than that: make it the size and style of the "do you want to accept notifications?" dialog. It should be unmissable by users that they're on an insecure site.
- Jaruzel 8y ago
  ... only if it did it for non private IP ranges. Otherwise all your home stuff would constantly be throwing up notifications.

angrygoat 8y ago

I don't think it's really about what end-users do with the warning, or whether they tune it out; site owners will not want a big "Not Secure" badge showing next to their page, right next to their domain / brand. This change creates a powerful incentive for sites to move over to HTTPS.

xg15 8y ago

> non-secured HTTP still makes sense for example during development or for home routers and printers where traffic encryption is less important compared to the initial UX I think this goes deeper. Currently, supporting HTTPS means you have to have some kind of internet connection, back-end infrastructure and other running costs. Even if you use Let's Encrypt and DNS validation, you will have running costs to keep the domain name registered and you will need some way to periodically transfer new certificates to your devices. Even if you somehow manage to update the device without a permanent internet connection, if someone wants to access the web interface, they will have to use the domain name - and therefore at least need to be connected to an internet DNS server so the domain resolves. So if, at some point, browsers would completely drop support for HTTP, this would suddenly force any kind of device with a web interface into an IoT-style lifecycle where the device loses functionality once its vendor is not able to support it anymore - even if the vendor would want people to continue using the device and even if there is no technical reason for it.

tialaramex 8y ago
Devices don't _have_ to prevent you from choosing their name. If I name the device my-funky-hatstand.tialaramex.example, then even if the Funky Hatstand company goes out of business and their domain name goes away, I can renew my certs, for my name. For a $5 product it may not make sense to have this level of configuration, but for example I believe the FireBrick (a device you might buy to put a small company or district office online) is capable of being configured with your name rather than a generic product DNS name that could go away. Also, just because a name is in DNS doesn't mean you must use the Internet to resolve the name. In a truly offline system you can just hard code that name resolution and it'll work fine. Nothing about HTTPS cares how resolution was actually done, only the BRs for the Certificate Authorities tell them they mustn't issue for names that aren't actually part of the public DNS hierarchy. So, the device needn't be on the Internet. The name must make sense in the Internet DNS hierarchy, but (with a typical commercial CA) needn't actually exist or (with Let's Encrypt, who insist on checking) needn't resolve to anything, let alone an actual machine on the Internet Yes, you will need to move new certs to a device if you want it to remain publicly trusted as time passes. If that's an unacceptable burden (maybe your device is under the North Pole ice) then you probably didn't want the Web PKI, you need your own PKI for your very special application. Most people want the Web PKI.

MaxBarraclough 8y ago

Agreed. I'm sure Google will take that into account if they decide to ramp-up the prominence of the 'warning'. As it is, the warning seems to be disabled for localhost/127.0.0.1 (where I only see a 'not secure' if I manually click the ⓘ) but the warning shows as usual if I browse a local IP address over plaintext HTTP.

vicbun 8y ago

> non-secured HTTP still makes sense for example during development To make it easier & cleaner in development, it's best to make yourself a Certificate Authority CA and issues local certificates. This makes for no warnings in browsers and ensures a better development experience. A post from my colleague on how to do it https://reactpaths.com/how-to-get-https-working-in-localhost-development-environment-f17de34af046 https://reactpaths.com/how-to-get-https-working-in-localhost...

pilif 8y ago
> To make it easier & cleaner in development, it's best to make yourself a Certificate Authority CA and issues local certificates sure. That's what I do on those sites where I absolutely need SSL even during development. But it's still a hassle and, I would argue, an overall security downgrade. If somehow that CA certificate gets out (commited to github by accident, extracted via malware, etc.), I become MitMable unless I manually check every certificate of every site I visit. I know that this isn't too likely an attack vector, but if I had to target a developer friend, that's something I'd look into because this has the potential to work across machines whereas traditional malware based solutions would only work on machines I can compromise. If you have unique CAs per development machine, this would of course be moot, but at that point, you might as well just run with a self-signed cert to begin with and allow the exception once.
- tialaramex 8y ago
  Certificates are public documents, it isn't a problem if everybody sees them. Committing the certificate is, at worst, a minor inconvenience for someone who doesn't want your certificate because they don't trust your CA. A _Private Key_ is the thing that needs to be kept private, in Microsoft Windows it's common to bundle this together with a corresponding Certificate in a single file, often with the filename extension .PFX I assume it's more "convenient" this way, shame about the security. If you do this a LOT (maybe you're a team of fifty developers at a software company that mostly builds web apps but has a strict policy of not using "real" certificates or wildcards) you should mimic the hierarchy required of "real" public Certificate Authorities: Mint a "root CA". You'll end up with a certificate and a private key, let's call them root-C and root-P. Every developer (and QA and so on) system needs to trust root-C, you can use Group Policy or similar tools to arrange that. Use the root CA to issue a sub-CA, the "issuing CA". Write _constraints_ in the certificate used to issue this sub-CA. A constraint is a rule about what things the Subject is an authority about in the opinion of the Issuer. So for example if you set a DNS constraint of just example.com, certs for example.org, or google.com from this Issuing CA don't work. If you later acquire example.org, you can "just" replace the Issuing CA. No updates to employee systems. Think about the Constraints you write, so that they block "mistakes" like MITMing google.com, but not anything you expect to actually need. You can also constrain the types of certs issued. Will you only issue TLS server certs? Then write a constraint saying so. Now, lock away root-P, a serious CA has it in a special hardware device to protect it, but a USB key in a locked desk drawer is a good first step. The Issuing CA credentials will probably need to stay live on someone's computer, they're valuable of course, but because of the Constraints they now aren't an unlimited black hole in your security.

epanchin 8y ago

Did they remove the “Secure” label too? Doesn’t say in the blog post.

Vinnl 8y ago
No, that will happen later.