Chrome kills the HTTP-HTTPS “mixed content” warning | Hacker News Reader

Chrome kills the HTTP-HTTPS “mixed content” warning

arstechnica.com

70 pointssmacktoward45 comments

I've been wondering about the value of these warnings to the 99% of end users who have no idea what HTTPS is, and who have even less understanding of why a site whose URL begins "https://" would be insecure. Firefox uses icons to indicate different situations but even I don't know what they mean.

I think the browsers need to indicate simply that the website is "secure" or "not secure", with some transparency for advanced users to obtain more details. Don't give end users information they don't understand about a topic they also don't know about and expect them to draw the right conclusion (in the miliseconds they spend thinking about each website); it will fail in its goal almost every time. (In a way, it's the same approach as click-wrap legaleze.)

That doesn't solve another problem: Properly implemented HTTPS doesn't really mean "secure"; it just means one component likely is secure. The site could be scam, user data could be exposed many other ways, HTTPS has vulnerabilities, etc. I don't know how to effectively inform end-users about those complexities.

It's rapidly moving towards where domain validated certs are shown as "normal" (grey), improper or no HTTPS is considered "insecure" (red) and extended validation certs are green with additional indicators.

This is already almost the case on most mobile browsers. Bunch of screenshots of DV vs EV display in browsers: https://www.expeditedssl.com/pages/visual-security-browser-s...

Edge is a massive improvement over IE11:

- The domain validated lock is now hollow as well as grey.

- There's way less activity in the address bar, so it's much more readable than IE11 was.

https://certsimple.com/blog/dv-ssl-in-microsoft-edge

Users still have trouble understanding what HTTPS entails. I work with security and most lay-people think it ensures the site is somehow trustworthy.

"Why are you typing your password on faceb00k.com?"

"It has a green padlock, it's safe."

I don't have any suggestions for this problem, but I think it should be acknowledged at least.

In theory, at least, a fraud website like faceb00k.com wouldn't be able to maintain a green padlock for very long because the issuer will revoke the cert.

Not saying that's a solution, but it mitigates the problem somewhat.

Are you sure that happens in practice? Unless you have an Extended Validation certificate, which verifies the company name, I'm not aware of any requirement against fraudulent uses, or precedent of certificates revoked because of that.

I know certificates must be revoked if the private key leaks (e.g. Heartbleed), but who is policing certificate use? Is there any place to send complaints? Can I email StartSSL or VeriSign and ask them to revoke faceb00k.com?

and what if they simply get a certificate from another source?!

> Can I email StartSSL or VeriSign and ask them to revoke faceb00k.com?

I think so, yes. I don't have any direct evidence to back this, but my intuition is yes, they would contact the intermediary cert issuer and request the certificate be revoked due to the fraud (assuming Verisign or StartSSL were in the trust chain of the cert).

Check out Trustico's website [0], where they say "Your domain name may be blacklisted and internet users will be wary to transact with your web site."

[0] - https://www.trustico.com/fraud/fraud.php

I didn't like the old warning, because it looked more like a yellow up arrow to me than an orange warning triangle (I am colorblind). At first I thought the old one meant the page had upgraded or better security. I don't like the new one much better, though. I'd prefer to have the red slash through it like the one that appears in some cases.

> I didn't like the old warning, because it looked more like a yellow up arrow to me than an orange warning triangle (I am colorblind)

Amazing. They don't seem to get basic color choices in UI design (particularly in a security warning, on a huge product such as Chrome), yet spend a million words rambling about material design and describing ripple effects on click/tap.

I can't imagine it's trivial to apply the same standards everywhere given the number of Google products and number of employees making decisions.

And yet this same company requires that we apply specific standards to our web pages lest we be deranked on their search engine. :)

Not sure why this is surprising. This is an entirely different team with different priorities. Look at any large company and you will see how they fail to utilize what another department has done or advocates.

Yes, you're totally right. Even companies which are in theory very design-driven (Apple, obviously) have blatant inconsistencies and different standards in different products.

Still, it's a security warning in a high profile product which is used, for many, as the main Internet client. There's really no excuse for not being careful about color blindness.

I am currently working on a project which must include content from third party CDN's. Unfortunately, lots of them do not support HTTPS at all. So while my site safely serves everything over HTTPS from origins I control, random images I'm including from elsewhere make it look like something is very wrong. Shouldn't at least CDN's at this point switch to HTTPS-only? There is no downside in including HTTPS resources in pages served over HTTP.

Yep, and my site includes photos from S3, and S3 can't be https (because my bucket name has periods in it, like Amazon suggested). I guess I'll have to proxy the images myself.

You can build an https Cloudfront distribution from your S3 bucket -- faster delivery as well.

https://aws.amazon.com/cloudfront/custom-ssl-domains/

You can still access it from https://s3.amazonaws.com/bucketname, no?

You're right. Last time I tried it Amazon told me that this format wouldn't work with my bucket (because it was created after a certain date), but now it does (with a different hostname). Thanks!

That's really only needed if you want a custom domain name... imho, I don't think it's really so bad if your resources (not your main content) comes from s3.amazonaws.com ... Most people don't look into the developer/resources section of their browsers, and most of those that would/could would figure out pretty quickly it was s3/aws if they wanted to.

It's kind of sad that people, and amazon itself felt the need to push towards that... Of course Amazon is big enough at this point, they could/should have their own intermediary setup (like cloudflare) for use with s3.... Of course they probably just want to make the money from cloudfront.

This is going in the wrong direction. "Grey" doesn't indicate anything to the user. Instead, they should make HTTP sites show up with a yellow triangle, because they aren't secure.

It's also a little silly to claim that it's hard to move to HTTPS all at once. Most sites are served up with web server such as Apache/nginx/etc. that wraps everything served up: it's easy implement HTTPS at that level. The other common option is a cloud service provider, and that's only a bit harder.

So no, this is not hard. I venture I could move most sites to 100% HTTPS in an afternoon if I had knowledge of the site, but even if you haven't done this before, there's no reason you can't do this in a week.

Eventually displaying HTTP as insecure is, in fact, the plan for Chromium:

https://www.chromium.org/Home/chromium-security/marking-http...

> The problem is, it's almost impossible to switch completely from HTTP to HTTPS in one fell swoop—there are just too many factors that need to be tested and debugged.

Such as? Article is a bit short on facts here.

> At the same time, webmasters weren't keen to begin the migration process to HTTPS because of that pesky mixed content warning, which had a tendency to spook less-experienced users of the Information Superhighway.

And rightfully so! There's no difference between mixed content and HTTP only for the purposes of data security. Just yesterday I noticed that a payments website had mixed content issues and elected not to risk my personal info. This change is even better because now you really can tell your family to "just look for the lock icon".

> Such as? Article is a bit short on facts here.

* Using JavaScript to access APIs that don't support HTTPS (NextBus)

* Embedding iframed content from sites that don't support HTTPS (Youku)

* Using CDNs for photographs and file downloads, using your own domain, and without paying a ton of money to get them to install your certificates (Imgix, Amazon)

> Such as? Article is a bit short on facts here.

It was recently documented that some ad mechanisms for which Google gets money wouldn't work.

> Such as? Article is a bit short on facts here.

You need to make sure every image, CSS, JavaScript and frame link on every HTTPS page is served over HTTPS. This might not be straightforward depending on how your site works. For example, if you're using a CMS, such links might be generated by CMS code and CMS plugins that you'll have to modify, and if post editors can embed HTML content in posts all posts will have to be checked. Also, HTTPS may not be supported by third parties you rely on.

The Chrome blog post says:

"Switching an HTTP site to HTTPS can initially result in mixed content, which is undesirable in the long term but important for debugging the migration. During this process the site may not be fully secured, but it will usually not be less secure than before."

Honestly, the old padlock-with-yellow-warning-triangle seems better than its replacement. Now a page which is insecure due to mixed content will look like a totally innocent https:// page! Yes, it lacks the padlock, but lots of Internet users are taught in school that https:// means secure.

Would subresource integrity fix this? Do web browsers mark TLS sites that link to non-TLS resources that have subresource integrity as mixed content?

As a result, in Chrome 46 (on desktop PCs, at least), there will be just three security states: a green padlock (full HTTPS), a red padlock (broken HTTPS), and a grey piece of paper (HTTP).

I can't say I've ever seen the red padlock. Usually if the site had broken HTTPS, Chrome would refuse to load it at all.

> I can't say I've ever seen the red padlock

I see one on news.ycombinator.com. Well, technically, a gray padlock with a red X on top of it.

Is there something that would intercept your connection to news.ycombinator.com and supply an invalid certificate?

Chrome seems to be quite happy displaying a green padlock for me when I visit Hacker News.

No, and if so, I would have received a much stronger warning.

After some investigation, it turns out that my computer had an old Comodo certificate that lacked certificate transparency information.

Sounds like MITM to me

You're probably on an employer-owned network? Their proxy is reading everything, and either they haven't set up a "fake" CA or you're using a BYOD that isn't configured with that fake CA.

That is true for me. Work does a man in the middle to inspect all traffic and I get the red X a lot. Don't expect any privacy at work.

Chrome refuses to load it, but offers you a link to go to the site anyway and then you see the red padlock.

Yes, this is how my staging server works. We use self-signed certs because it's just us and the hackers. This gets us the red X through the grey padlock (on linux chrome anyway)

I see it regularly when I'm doing dev work.

> The problem is, it's almost impossible to switch completely from HTTP to HTTPS in one fell swoop—there are just too many factors that need to be tested and debugged.

It's not impossible or 'almost' impossible. It's just hard, and requires work.

Is it April 1st already? Wonder which new product manager came up with this glorious idea. "less information is better. Let's not trouble our poor users with too technical stuff"

Are there any plans from any of the browsers to show HTTP sites as insecure, rather than as some sort of "normal" state?

From the (5 paragraph) article: "In the long term, Google eventually plans to reduce Chrome's security states to just two: secure (full HTTPS) and non-secure (everything else)."

And the actual proposal: https://www.chromium.org/Home/chromium-security/marking-http...

See "Marking HTTP as Non-Secure" from Chromium:

https://www.chromium.org/Home/chromium-security/marking-http...

and "Deprecating Non-Secure HTTP" from Mozilla:

https://blog.mozilla.org/security/2015/04/30/deprecating-non...

Some versions of IE with default configuration won't load the insecure content and generate an alert.

Reply on news.ycombinator.com