Live data from Hacker News

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

security.googleblog.com

371–380 of 419 posts

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

#371
post #223

Earlier quoted context omitted.

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

I guess a part of this is inconsistency between development environments as well, but generally speaking, while not completely impossible, the dev user experience is just that bit more fiddly. For a prod server, the process can be as simple as (Ubuntu/Apache being a common setup): apt-get install letsencrypt && certbot --apache Or more generally: $PKGMGR install certbot && certbot certonly For dev, you need to either…

You could use a tool like easypki that allow you to manage a testing CA, whose root cert you can import into your browser. Maybe use a different browser profile so a compromise of the CA keys would not allow anyone to compromise your banking sessions, too.

https://github.com/google/easypki

But sure, if you're using Let's Encyrpt in production, this won't approximate your production setup in testing.

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

#373
post #66

Earlier quoted context omitted.

I'm fairly sure that violates PCI-DSS.

PCI-DSS is okay if you put it in an HTTPS iframe. Many sites I've seen use that workaround.

TNope that would violate PCI as well since you are then subject to clickjacking attacks unless you configure the site to only allow framing in from a specific url.

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

#374

Earlier quoted context omitted.

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

> the router would come with a custom burned-in key that it would use to authenticate itself to the CA and get the cert I take apart the router, and get a valid certificate. Now I hijack DNS, and get you to connect to me. HTTPS within LAN for this purpose is useless.

I take apart the router, and get a valid certificate

You only get a valid certificate for your router's address. But if you can take apart the router, you don't need to hijack the DNS, you can simply control its traffic.

But if you're a guest in my home and I see you take apart my router, you'll have to answer a few questions. Same in an office or coffeshop. Having LAN access doesn't mean you have complete physical control of the router. So the HTTPS is not useless.

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

#375

Earlier quoted context omitted.

Firefox has started to do this recently "Note that is warning in the url bar is only in Firefox Nightly and Firefox Developer Edition. This has not been released to Firefox Beta and Firefox Release."[0] So this is not a security feature that most end users can rely on, yet. [0] - https://developer.mozilla.org/en-US/docs/Web/Security/Insecu...

Looks like that url lost its final char [1] I use DE, so I have been seeing these for a little while, but I think even in the stable channel you can toggle the security.insecure_password.ui.enabled param to true in about:config. 1: https://developer.mozilla.org/en-US/docs/Web/Security/Insecu...

Well it will soon land in stable as well I am sure. But its amazing to see major browsers moving in this direction and educating users about security.

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

#376
Ultimately, how is this plan by Google going to affect sites that are hosted on a virtual server hosting plan?

For instance, I have a website hosted at Hurricane Electric on a virtual server plan. I've had hosting there for well over a decade. I like their service, the virtual host works well for most of my needs. There are two areas where it doesn't work, though (AFAIK):

1. I can't run a pure NodeJS website.

2. I can't set up HTTPS.

Number one isn't relevant to this discussion; but as far as I know, the second one is a big deal. There isn't any way (AFAIK) to host multiple virtual servers each with their own certificate.

So right now (well, with the release of v56 of Chrome) - if you have a Wordpress site or something on a virtual host that has a login - it's going to show something that says "unsecure" for the login/password form. Honestly, I am fine with that. My own site isn't a Wordpress site, but I do have a login/password box on the site, and having it show that it is insecure is not a big deal to me. While there isn't much or anything I can do about it, I do understand and support the reasoning.

But...

...in the future, they want to mark -all- non-HTTPS sites as "insecure" - regardless of what the site does, presumably. It could just be a collection of static html pages (no javascript, no forms, nothing special), and it will still be marked as "insecure"? Does this sound reasonable? Suddenly, all of these pages will be deemed pariahs and non-trusted because they choose to use non-encrypted means of presentation?

Is there any solution to this, as it stands? Or are all of us with virtual hosting solutions going to have to migrate to some cloud-based server solution, with it's own IP, then obtain our own certificate (easier today, I know - and cheap to free, too) - just to get around this? Is this the end of virtual private server hosting (or is it going to be relegated to third-tier)?

I don't currently know what if anything Hurricane Electric plans to do regarding these changes. I don't want to move to another hosting provider if I can avoid it (while HE isn't the cheapest for what you get, they are nice in that they assume you know wtf you are doing - your hosting is basically access to the server via ssh and sftp - so you better know how to admin and set things up via a shell, because they aren't going to hold your hand).

I'm thinking I should send an email to them to ask them what they're planning to do - if anything.

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

#377
post #225

Earlier quoted context omitted.

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!

Hell, even shared hosting like Dreamhost which I use for a number of old projects I host for other people has built in LetsEncrypt functionality. I was setting up a WP blog for a family member the other day and saw the option and it was super easy. I've added to my backlog to go turn it on for all my other sites as soon as I've confirmed it won't break anything (ie. loading assets using absolute urls that use http. B…

> Hell, even shared hosting like Dreamhost which I use for a number of old projects I host for other people has built in LetsEncrypt functionality.

How do they do this? How do you set up an SSL cert on a shared host (aren't SSL certs tied to an IP)?

I have a site on a virtual host (via Hurricane Electric), and I don't want to move to another hosting provide (cloud hosting) if I can avoid it. But unless something has changed (which I admit, it may have - I am not up on all the latest web hosting tech), my understanding was that you can't have an SSL cert on a virtual host.

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

#378

Earlier quoted context omitted.

PCI-DSS is okay if you put it in an HTTPS iframe. Many sites I've seen use that workaround.

TNope that would violate PCI as well since you are then subject to clickjacking attacks unless you configure the site to only allow framing in from a specific url.

[deleted]

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

#379

Earlier quoted context omitted.

PCI-DSS is okay if you put it in an HTTPS iframe. Many sites I've seen use that workaround.

TNope that would violate PCI as well since you are then subject to clickjacking attacks unless you configure the site to only allow framing in from a specific url.

> The Hosted PCI Web Checkout module allows merchants to take credit card information on any page of their website. This includes checkout and my account pages. Hosted PCI uses an “Iframe” that can be easily installed on any website. Our Iframe is secure and is 100% Level 1 PCI Compliant. Our merchant’s websites never see the customer credit card information. That means, our merchants websites are not in scope for PCI Compliance requirements so you don’t have to spend time or tens of thousands on PCI audits yourself!

http://www.hostedpci.com/checkout-express/

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

#380

Earlier quoted context omitted.

What are you talking about? There are plenty of low-cost VPS providers that give you full root access on which you can easily run certbot. That's what I'm doing now, and my hosting provider costs a whopping $20/year. Say what you will, but pushing for passwords to be transmitted securely isn't Google fighting against the democratization of the Internet. They're doing that in other ways, sure, but promoting encryption…

Encryption could be offered without certification authorities that charge huge sums for certs. And there's a link on /new right now about Symantec which continues to reinforce how relying on CAs is a broken concept. So, right now, I have 24/7 American-based phone support (this is a must-have), 99.9% uptime guarantee, WHM/cPanel software licensing included, 60 GB disk space, 600 GB bandwidth included. By all means, if…

Have you thought about using that 24/7 phone support to ask them to upgrade cPanel? Since August it comes with LE support in the form of the AutoSSL plugin.
Post reply on HN