Chrome 56 will mark HTTP pages with password fields as non-secure • Hacker News Board

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

#221

Post by jrockway » Mon, Jan 23, 2017, 1:06 AM UTC

Yver wrote: post #218

twblalock wrote: post #156

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?

I think the use case is people browsing your site in a coffee shop. They wouldn't shout their password for everyone in the room to hear, but that's exactly what their computer's doing. Yeah, probably nobody overhearing the password is going to use their account to start posting embarrassing nonsense. But it's good for their user agent to inform them that that could happen.

State-sponsored actors aren't going to try to brute-force the encryption so they can post to your aquarium forum, that's true.

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

#222

Post by icebraining » Mon, Jan 23, 2017, 1:07 AM UTC

ec109685 wrote: post #188

BinaryIdiot wrote: post #119

Earlier quoted context omitted.

> who is in a position to tap your connection such that this becomes a serious security concern? When you use HTTP everything is sent in plain text. This means... - Anyone on the same network as you can see all of your traffic. This includes company networks, coffee shop wifi, your house, the library; any place that has a WiFi network. Caveat: it's possible to use network isolation to hide your traffic but this is cr…

If I have two devices connected to a switch, how can they see each other's traffic?

ARP poisoning[1]. Ettercap lets you do it with a couple of clicks, without any advanced knowledge.

[1] https://en.wikipedia.org/wiki/ARP_spoofing

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

#223

Post by slrz » Mon, Jan 23, 2017, 1:07 AM UTC

lucideer wrote: post #81

SilasX wrote: post #70

Stupid question: Is the warning going to show up for localhost i.e. using chrome to see the local dev version of your website?

It has for me with the Firefox version of this, and based on my experience of it sofar, this is fine. For one, it's an obvious differentiator between my local copy and live, but secondly I also think local certs are something that we really need to find a way to make easier for devs to set up and test with.

Where do you see the issue? Creating a certificate that no one else has to trust seems pretty easy already.

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

#224

Post by jrockway » Mon, Jan 23, 2017, 1:10 AM UTC

nommm-nommm wrote: post #220

iancarroll wrote: post #217

Earlier quoted context omitted.

It can indeed take some time to switch over, but why would you intentionally suppress a correct warning in the meantime? There is no good reason to mislead users here.

Because, here in the real world, my paycheck depends on keeping my customers happy.

How happy will your customers be when they find out that you're just pulling the wool over their eyes instead of doing your job?

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

#225

Post by ripdog » Mon, Jan 23, 2017, 1:11 AM UTC

Yver wrote: post #218

twblalock wrote: post #156

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?

Yes. Every website. Because if only the sensitive sites are strongly encrypted, then bad actors and authorities know exactly where to focus their efforts in trying to steal information. When everyone is strongly encrypted, attackers are stretched much more thinly.

Besides, it's easy and free these days. Unless, apparently, you use some crappy shared hosting provider. Get a VPS, man! They're cheap!

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

#226

Post by detaro » Mon, Jan 23, 2017, 1:15 AM UTC

Moru wrote: post #76

kevin_thibedeau wrote: post #71

Earlier quoted context omitted.

Why would such a form need a password field?

Well, that is the whole point I'm trying to make. Why does chrome think I'm using a password on the page when there is no password? Anyway, Chrome will mark all http as insecure sooner or later so will just have to force https on all connections... There seems to be many people with similar problems of false positives for nonexistant passwords so I guess it's a bug.

Then that's a bug you should report, and let the Chrome team fix it.

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

#227

Post by icebraining » Mon, Jan 23, 2017, 1:16 AM UTC

kuschku wrote: post #163

nsgi wrote: post #63

Earlier quoted context omitted.

The best solution is for them to be accessed through a publicly registered hostname e.g. https://router0123.netgear.com (that would only resolve locally). They could provision certificates for themselves using the Let's Encrypt DNS challenge.

So, now we have a single certificate on all routers? What happens if I take apart a router? Or would every router get its own certificate? But then netgear would have to become its own CA. And in either case DNS hijacking is a massive issue.

Or would every router get its own certificate? But then netgear would have to become its own CA.

Why? They could just partner with an existing CA, like Cloudflare does with Comodo.

And how would DNS hijacking be an issue? The attacker wouldn't be able to produce a valid cert anyway (the router would come with a custom burned-in key that it would use to authenticate itself to the CA and get the cert).

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

#228

Post by michaelbuckbee » Mon, Jan 23, 2017, 1:17 AM UTC

Yver wrote: post #218

twblalock wrote: post #156

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?

I think of it like herd immunity. Users typically reuse passwords between sites, so if leaches the passwords out of the aquarium forum they may get their Gmail password as well, etc.

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

#229

Post by LogicX » Mon, Jan 23, 2017, 1:20 AM UTC

It's great that Google wants to move more sites to https, and I'm in support of this, but it also creates challenges for security vendors such as myself.

Currently DNSFilter and others Man in the Middle traffic destined for sites our customers have decided to block. This works great for http, but not https, as certificate warnings are presented.

The standard work around is arguably less secure: adding a third-party CA to all end-points. This can still present problems with HSTS and certificate pinning.

I'd like to work with Google to create a standard where vendors can either be on a whitelist or have new recognized SSL cert fields, not to MITM traffic, but just to present users with a friendlier message explaining whats happening, and providing a separate https:// url to visit for information from the vendor about the block.

Implementing such a standard in browsers would further increase user security, and provide a viable method for filtering on guest networks where there is no end-point access.

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

#230

Post by gregmac » Mon, Jan 23, 2017, 1:22 AM UTC

clamprecht wrote: post #111

What if the submits to an https page but the page is served up on an http page? The form submission will be secure, correct? Will Chrome still mark as insecure?

I was also thinking of the opposite: submitting from an https-loaded page to an http page. I can't imagine why any application would do this (other than by mistake), but it would ideally be flagged as insecure as well.