Live data from Hacker News

Chrome 56 will mark HTTP pages with password fields as non-secure

security.googleblog.com

341–350 of 419 posts

Re: Chrome 56 will mark HTTP pages with password fields as non-secure

#341

Earlier quoted context omitted.

As someone who runs like a roleplaying site for like ten people (or several of them), I cannot be responsible for other people's bank passwords, nor should I be punished for daring to host websites without the huge added burden of cost of HTTPS. The notion that every homebrew website is supposed to support HTTPS is also never going to describe reality.

You should not be responsible for running any of the sites with this attitude.

Again, this is not a productive or useful security attitude to take. We've made some grave privacy missteps with poor security advice time and time again, so simply saying "HTTPS is better and everyone should use it" is not inherently accurate. Especially when it's completely impractical with the tools available.

Re: Chrome 56 will mark HTTP pages with password fields as non-secure

#342
post #218

Earlier quoted context omitted.

> Now all my users are going to hear that my site is insecure, when nothing at all changed. You're being pretty irresponsible if you aren't using SSL for passwords. You users should be told that your site is insecure, because it is. You should care more about the security of your users. If your hosting does not allow SSL, you have an obligation to change hosts for the safety of your users. If you aren't willing to do…

"insecure", "huge red flag." For a banking site, an e-commerce site, a webmail, sure. Must an aquarium enthusiast forum be resistant to Man-in-the-Middle attacks? What about weak ciphers? Should every site be resistant to offline decryption by a state actor?

Do you ask for personal information as part of your signup process? First name, last name, email address etc? If you don't encrypt the data or take basic precautions against unauthorised access you're likely breaking Data Protection law.

If you've already implemented a web server with SSL then "weak cyphers" might bother you. As you don't already have it configured, you're no worse off configuring a fully TLS 1.2-compliant web server with SHA256 signed certs and ChaCha20-Poly1305 cypher suite. It's just a configuration option if you're doing it for the first time.

Re: Chrome 56 will mark HTTP pages with password fields as non-secure

#343

Earlier quoted context omitted.

Have you tried Amazon Lightsail or Digital Ocean? Both of them give you more than a paltry 1 GB for their $5/mo plans.

Seconding DigitalOcean. You can get a 20GB SSD + 1000GB xfer for $5 a month.

Recommending against DigitalOcean: https://gist.github.com/justjanne/205cc548148829078d4bf2fd39...

TL;DR: Too expensive.

(And, additionally, they tend to fuck over customers who paid for their money. "100$ free credit!". "You only need to pay 5$ to activate your free credit!". "Sorry, but because you didn’t use it, we removed your free credit!")

Re: Chrome 56 will mark HTTP pages with password fields as non-secure

#344

Earlier quoted context omitted.

Kinda like how your antivirus tells you about how the formidable threats it saved your ass from today? Or like "did you know your house COULD have been ransacked today, but it didn't happen!!" Now all my users are going to hear that my site is insecure, when nothing at all changed. How long ago did they announce that? I think just a couple months? They should have announced this much sooner. It's going to hit me hard…

In my country and probably a lot more, you'd be held legally responsible if by any means customer data would leak out. Be it stuff sent over a wire unencrypted, or an account with administrator access being compromised due to unencrypted password transfer. I dare you to go to a hacker or security conference once, just for kicks. Connect to any wifi there, log in. See what happens.

I don't have "customers" though. I thought this was implicit but maybe I needed to clear that up. Sure makes no difference to security. But that is the consideration when Google pushes everyone to have to buy SSL, even those who just have a hobby. I've just been venting frustration a little bit as to seeing the web change from the playground it used to be to a much more regulated thing, but so it goes. Times change :)

Re: Chrome 56 will mark HTTP pages with password fields as non-secure

#345

Earlier quoted context omitted.

Like every other person who started a forum some years ago or a wordpress blog you mean? Do you think web hosts offer SSL by default? NO they don't. Duh. That's what is annoying in these comments. Everyone seems to shrug like SSL is standard feature nowadays, except is isn't.

That's the point. SSL/TLS is a standard feature nowadays. If you're a web host and you don't support certs or charge some unreasonable fee for adding them (and I'm well aware there are far too many of these out there), then you need to be losing business fast. Your customers should be moving to better competitors. This measure just accelerates this process.

True, it's just the transition atm is a bit painful.

My host is asking ~80 USD for multi domain SSL. It's not that bad, but they don't support Let's Encrypt yet afaik. Are they aware of this and trying to cash in on people who don't want the hassle of moving their sites?

On the other hand, if I buy there is none of that "auto renew" business...

Re: Chrome 56 will mark HTTP pages with password fields as non-secure

#346

Earlier quoted context omitted.

Their IT guy?? There are gazillions of people like me who have a blog, or some small project that has a small audience of tens to just a few thousand users. All these people now have to fork for SSL, or have to move everything to a different shared hosting that supports Let's Encrypt.

Your shared hosting service doesn't need to support Let's Encrypt, it just needs to allow you to upload a certificate. You can use https://gethttpsforfree.com/ to generate it.

They want an "installation" fee.

And then how does the renew process work?

Re: Chrome 56 will mark HTTP pages with password fields as non-secure

#347

Earlier quoted context omitted.

> Now all my users are going to hear that my site is insecure, when nothing at all changed. You're being pretty irresponsible if you aren't using SSL for passwords. You users should be told that your site is insecure, because it is. You should care more about the security of your users. If your hosting does not allow SSL, you have an obligation to change hosts for the safety of your users. If you aren't willing to do…

I've never said SSL isn't important nor that I don't care about it. My beef is how Google forces this change on everyone, but at the same time haven't the balls to shake things up and make SSL easily available for everyone. Of course as there is a massive business out there selling empty air "certificates" which are jsu tnumbers on a database requiring next to no maintenance, for princely sums. THAT is lame on Google…

What legitimate reason do you have not to use SSL? It's free.

Are you really saying that your site would be no more secure with SSL? Because that is objectively, provably false. If your clients are paying you to make sites like this that is borderline professional malpractice.

Re: Chrome 56 will mark HTTP pages with password fields as non-secure

#348

Earlier quoted context omitted.

Kinda like how your antivirus tells you about how the formidable threats it saved your ass from today? Or like "did you know your house COULD have been ransacked today, but it didn't happen!!" Now all my users are going to hear that my site is insecure, when nothing at all changed. How long ago did they announce that? I think just a couple months? They should have announced this much sooner. It's going to hit me hard…

>Or like "did you know your house COULD have been ransacked today, but it didn't happen!!" >Now all my users are going to hear that my site is insecure, when nothing at all changed. I'm not sure you should be allowed to drive a webserver.

I'm not sure what the "driving" equivalent is for a battleship, but I'm pretty sure you do that to a server, not drive it.

Commandeer?

Re: Chrome 56 will mark HTTP pages with password fields as non-secure

#349

Earlier quoted context omitted.

> Now all my users are going to hear that my site is insecure, when nothing at all changed. You're being pretty irresponsible if you aren't using SSL for passwords. You users should be told that your site is insecure, because it is. You should care more about the security of your users. If your hosting does not allow SSL, you have an obligation to change hosts for the safety of your users. If you aren't willing to do…

I've never said SSL isn't important nor that I don't care about it. My beef is how Google forces this change on everyone, but at the same time haven't the balls to shake things up and make SSL easily available for everyone. Of course as there is a massive business out there selling empty air "certificates" which are jsu tnumbers on a database requiring next to no maintenance, for princely sums. THAT is lame on Google…

If people entered their good passwords on your site without noticing that it was unencrypted, then great, they should now consider that password compromised... As a user, as soon as I notice it's unencrypted, I'm _going_ assume the password is also probably not encrypted nor salted, and other users will probably have done so.

(Of course, even better would be a different password per site, but...)

Re: Chrome 56 will mark HTTP pages with password fields as non-secure

#350

Earlier quoted context omitted.

I think you could probably just point your DNS at Cloudflare to proxy your site through them; their service includes SSL plus some extras like caching and such for free. I've used them for a handful of projects and it's worked great.

That said it will still be insecure because of the unencrypted path from cloudflare to you server but it will hire the error

Hmm, so let's say I'm hosting my static files on S3. I've currently got CloudFlare setup in front of it but that apparently doesn't help.

Anything I can do other than not using S3?

Post reply on HN