Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

security.googleblog.com

Post reply on HN
Print view View original

391–400 of 419 posts

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

#391

Post by kuschku »

icebraining wrote: post #374
kuschku wrote: post #331

Earlier quoted context omitted.

> 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 c…

You only get a valid certificate for your router's address.

Considering basically every router has the same address, I now have a valid certificate for basically every router.

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

#392

Post by Sir_Substance »

NTripleOne wrote: post #348
Sir_Substance wrote: post #195

Earlier quoted context omitted.

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

Commandeering web servers will probably get you arrested ಠ_ಠ

I don't know what you do with a battleship. Helm it, maybe?

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

#394

Post by icebraining »

kuschku wrote: post #391
icebraining wrote: post #374

Earlier quoted context omitted.

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 c…

You only get a valid certificate for your router's address. Considering basically every router has the same address, I now have a valid certificate for basically every router.

Considering basically every router has the same address

They have the same IP address, not necessarily the same DNS hostname, which is what the certificates are tied to. The user would just be told to connect to the hostname (possibly printed in the sticker) rather than to the IP.

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

#395

Post by Vendan »

cr0sh wrote: post #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 ca…

If you are talking about this service: http://he.net/web_hosting.html, then it's supported SSL since 2013, at least, with a simple admin panel to set it up... If it's an actual VPS, then SSL is fully on you, and trivial to set up with common stacks and LE.

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

#396

Post by nickik »

geofft wrote: post #259
dsp1234 wrote: post #253

Earlier quoted context omitted.

Shower Thought: Why doesn't the browser hash the inputs for all password fields, then compare them when attempting to submit a form, and alert the user that they are doing something insecure?

Because my passwords for google.com, gmail.com, youtube.com, and google.co.uk are exactly the same, and the browser has no way of knowing that that's okay. (Google specifically has probably rerouted everything through google.com these days, but the general problem exists.)

Its a real problem, in the new anti-phishing protocols (U2F/UAF) have some ideas.

The Web Origin Concept - https://tools.ietf.org/html/rfc6454

The also require the server to provide a list of Origins that are valid for the protocol, if the domain your logging into is not in the list, the challenge of the server will not be signed. Its called AppID in the protocol.

See: https://fidoalliance.org/download/

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

#397

Post by nickik »

ChristianBundy wrote: post #49
skybrian wrote: post #29

Earlier quoted context omitted.

But that would make it worse for people on mobile.

Man, someone should really invent a way to make webpages respond to the dimensions and capabilities of the user's device.

Stop making up technology

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

#398

Post by caf »

nsgi wrote: post #296
tialaramex wrote: post #248

Earlier quoted context omitted.

I think the idea is each device has its own FQDN, and gets its own certificates. Thus, breaking open your router only gets you "your" private key, they'd all be different. Buying one on eBay might be risky, but if you buy sketchy network hardware on eBay you're at risk in so many ways already... You can't do this with Let's Encrypt out of the box (unless you make small numbers bespoke devices) because of their Rate L…

Correct. The rate limits for the parent domain wouldn't apply if it was added to the public suffix list. The IP restriction wouldn't apply because every router would be requesting from a different IP.

This doesn't make a whole lot of sense as a viable deployment strategy. The routers would necessarily need to ask for the domain name in question to be pointed at their internet-facing, public IP (if indeed they even have one!), because that's all that Lets Encrypt could possibly verify, but the administration interface is usually on a private RFC1918 address. And what secure protocol are you going to use for the router to request that domain name update?

And how is first time setup supposed to work anyway? You need to connect to the administration interface to give it your ISP credentials before it can connect to the internet and obtain its Lets Encrypt certificate.

If you forget about Lets Encrypt and instead point hundreds of thousands of router-.vendor.com addresses at 192.168.0.1, with a pre-made certificate, you then only have the problems of baking an individual private key into each router at the factory and boxing customised documentation (like maybe a sticker on the router itself) telling the user what the unique domain name is they need to setup their device. Oh, and the problem of what to do when the user wants to change the local address used by their router.

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

#399

Post by PaulBurke »

I must say that this is the essential step that has been taken by Google in order to protect user’s information in the latest version of Google Chrome56.

There are the number of hacks and vulnerabilities and the numbers have been increasing, and there the number of audience or people, who are not aware of this essential security.

Hackers may breach their identities, including user_id, password, financial details, banking information, etc...

Certainly, addressing a user about “Not Secure” page with little warning in the address bar will help them before they put their valuable information in a website. It’s prerequisite now that every website must have encryption to retain the interest of the user in a website.

So, such steps from Google will make the user aware of their basic security needs.

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

#400

Post by axman6 »

Vinnl wrote: post #350
simcop2387 wrote: post #149

Earlier quoted context omitted.

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?

Use CloudFront? Took me about an hour to set up for my S3 based blog, free TLS, http/2 and IPv6 without any setup apart from a checkbox.
Post reply on HN