Slashdot Mirror
Chrome 43 Should Help Batten Down HTTPS Sites
River Tam writes The next version of Chrome, Chrome 43, promises to take out some of the work website owners — such as news publishers — would have to do if they were to enable HTTPS. The feature might be helpful for publishers migrating legacy HTTP web content to HTTPS when that old content can't or is difficult to be modified. The issue crops up when a new HTTPS page includes a resource, like an image, from an HTTP URL. That insecure resource will cause Chrome to flag an 'mixed-content warning' in the form of a yellow triangle over the padlock.
Welcome to 2013.
Gives a better summary "The next version of Chrome will include a new security policy that may make it easier for developers to ensure “HTTPS” websites aren’t undermined by insecure HTTP resources."
Perl Programmer for hire
This is something even IE has done for years.
NO FIRST FOR SYSTEMD? NO FIRST FOR YOU! Filter error: Don't use so many caps. It's like YELLING.
If one of the the biggest banks in my country pulls in background images from http, on there https secure account login page, this can't be a security risk, can it?
When everything fails, you sell your soul to Satan and decide to fire up, gasp, internet explorer. For some odd reason it manages to get past all the hurdles gets the network extender running. Satan is laughing at St Murphy. St Murphy never loses, his revenge will come soon, and it will be swift.
In the meantime, caught as a mere pawn in the eternal battle between Satan and St Murphy I am ruing my fate and belly aching in slashdot.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
After all, we aren't in the days where pages could be returned in place of images and somehow still get parsed by web browsers like in days of old.
Holy shit that was an awful bug.
Can still be used for tracking though.
What a shock, a slashdot summary that misses the actual salient point of the linked article...
Here's the description of the new feature from the linked article:
Here's Google's own description of the feature from the Chromium Blog:
So basically this means you don't have to worry if you accidentally miss an HTTP asset link on your site when upgrading to HTTPS, Chrome will automatically do that for you.
Hopefully the other browsers will follow suit soon, otherwise it's of limited use.
Paul Leader
So instead of going through and changing your pages to use https:/// they want you to go through your pages and add a meta tag. (Yes I did read that there is an option to set it at the server level.)
Run grep on every article (or SELECT from your database) and on every script for http[^s]. Then open a bug for every one of them you find. You're done when every bug is closed and every regression test passes.
Oh shit, I forgot, web developers aren't engineers and aren't capable of doing the above. So this is really hard and can't be solved except by brilliant Google.
Create a plugin for a browser so that when you come across a page that has mixed content it finds out the contact information for the site and sends them a message how stupid they are automatically. Stop bugging me with warnings since I can't do anything about it. It's time to inconvenience the bad developer who made the page until they fix it.
Nice try, but this is significantly different from what Firefox does.
From TFA:
The directive “causes Chrome to upgrade insecure resource requests to HTTPS before fetching them”, Google explained today.
TFA's link to chromium.org essentially says the exact same thing:
Upgrading legacy sites to HTTPS
Transitioning large collections of unmodifiable legacy web content to encrypted, authenticated HTTPS connections can be challenging as the content frequently includes links to insecure resources, triggering mixed content warnings. This release includes a new CSP directive, upgrade-insecure-resources, that causes Chrome to upgrade insecure resource requests to HTTPS before fetching them. This change allows developers to serve their hard-to-update legacy content via HTTPS more easily, improving security for their users.
Converting to plain English: If the URL says "http://", Chrome will first try the same link with "https://". You'll only see a mixed-content warning if the website fails to return content for the "https://" link. This obviously assumes that the website is running both HTTP and HTTPS, and that it will give the same content regardless of whether you use HTTP or HTTPS.
Your link to Firefox 23 only talks about issuing warnings for mixed content; it does not say anywhere that it attempts to retrieve the HTTPS version of an HTTP link.
tl;dr: Firefox just blocks it; Chrome looks for a safe alternative and only blocks if the safe alternative doesn't exist.
[ Disclaimer: I use Firefox; I have never used Chrome. ]
Ahem.. https://www.eff.org/HTTPS-EVER...
The HTTPS Everywhere is a great idea, but how great when so many use self signed certs. This just gives the illusion of security. One of the biggest problems here is that browsers don't recognize legit free third party cert authorities like CAcert.
Revolution is the opium of the intellectuals.
So what this really says is lazy website programmers will no longer have to go fix their old http links, the browser will do it for them, so they can leave their old links forever and not have to fix them.
More info on Security Now #502
AC comments get piped to
For a good long while it's been annoying when dealing with mangled SSL configurations - at least firefox let's you tweak stuff in about:config to work around them.
No, getting the site fixed is not always an option, and validation of the certificate is not always necessary. For instance, there was a good long while where Chrome was completely unusable with some of our ZFS storage appliances (which live on a nonrouted private management network) because of retarded cert validation changes. Sure, that makes sense when you are visiting your bank's site... but not so much when you're trying to get into something on 10.0.0.0/8 when you're directly connected to the thing with a crossover cable... and no, updating the software in the controller wasn't an option because of outstanding critical-level bugs.
Fun times.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Godawful editing on Slashdot? Say it ain't so.
The summary is that they are introducing a new http header, this can be used to tell the browser to automatically use https instead of http to request resources used by the page. Thus avoiding "mixed content" warnings without requiring the website operator to go through the whole page (and potentially things like stylesheets referenced by the page) changing urls to https.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Thank the lord google has made the internet safe after such a long unsafe period of time since 199?.
The push for https everywhere also means there is more metadata floating around. If all your are looking at is the metadata and not the data stream, https gives an observer more info about what is going on than with just http. Once you get into properly verifing certs, both sides and an observer has more info to tie a converstaion between a specific client and a server.
You can see this yourself by getting something that does netflow and look at the data that comes from that.
Thank the lord google is making the internet safe after the long unsafe period since 199?
If you want people to give a shit about HTTPS, get rid of the SSL certificate mafia bullshit.
Yuck that chrome feature is horrible. You dont want to work around poor content from web sites, that just gives them an excuse not to fix it. Chrome should block the content like the other browsers do! Although in practice, most web sites should be fixed by now anyway. I know I fixed the content at my previous employer a few years ago because of FFs behaviour.
From https://www.chromestatus.com/f...:
This feature allows authors to ask the user agent to transparently upgrade HTTP resources to HTTPS to ease the migration burden.
So it is the content provider which decides if this is being used.
It is not only a Google thing, check the Firefox bugzilla:
https://bugzilla.mozilla.org/s...
And the W3C Draft:
https://w3c.github.io/webappse...
This is in my opinion a good thing, it leaves all control in the hands of the content provider and supports the move to encryption everywhere.
Sounds like it. And really this is of little value for serious web publishers. Changing the links is the easy part -- it's getting third-party providers to *support* HTTPS that's the hard part. This includes providers like ad servers, analytics providers, behavioral targeting systems, and embedded content. A large publisher may have 30-40 partners providing embedded elements throughout the site.
...until sidetabs come back (or Google lets addon authors replicate it fully), Chrome sucks.
One thing TLS does is make sure that only you can post comments under the name fahrbot-bot, not somebody who copied your cookies by looking at your HTTP headers.
This is pretty useless if other browsers don't adopt the same model.
It just means some webdevelopers that forgot to test something in other browser might end up breaking sites unknowingly.
New things are always on the horizon
Like bugs in features that people actually want to use - http://ark42.com/chrome/
Morphing Software
How come java does not support java anymore?
If you are chrome you do; because poor websites are a method to target your users.
If we were talking about google building this into chrome; so that they could then generate content on their own web servers that don't use SSL (but would with Chrome and no one else) then complain.
Chrome is for users, shitty developers make shitty websites; and perhaps chrome should include a not-so-bad "This warning indicates your website is secure, but wanted to not be" (uinstead of the usual "This website is unsecure and shit and your life is ending" error message they give now for mixed-content)