10 ms·

Chrome to block insecure resources by default

48 points by abraham 15y ago

deleted 15y ago
[deleted]
ojilles 15y ago
Awesome, looks like a good idea to me! It should also not be very destructive as most legitimate websites already try to eradicate mixed (secure|insecure) content.
runningdogx 15y ago
In an https page, why not rewrite http resources to https by default? Then it could omit the content if there is a cert error or if there is no ssl server there at all. I'm thinking of a use case of a typical not-ssl-mandatory online forum/wiki/whatever. There are going to be tons of historical img and script tags, either to local content or to other sites, that do not use https even when they could; when those links were set up years ago very few sites (other than ecommerce) took ssl seriously. The solutions are going through and changing links in the database, rewriting links in the app, or rewriting links in the web browser. Is there a compelling reason why rewriting links in the web browser is bad? There are five web browsers that people care about: Chrome, FF, IE, Safari, Opera (mostly mobile). There are thousands of webapps and at least tens of thousands of moderately popular sites that would have to rewrite content in the database or webapp in order to go ssl-only.
- bonzoesc 15y ago
  In a shared hosting environment, http and https might go to entirely different sites.
  - falcolas 15y ago
    As well as any content hosted on a CDN.
- gst 15y ago
  Yes there is a compelling reason: It's not the task of the browser to do this. With such an ugly hack you gain some short term benefits at large long term costs. I guess about 15 years ago someone asked: "Why not let the browser try to interpret broken HTML instead of showing an error page?". The result is today's security nightmare, where it's impossible to reliable prevent script injection into HTML pages, because you can't just block the "official" way to insert a script, but also need to look into each of those ways how an HTML engine might interprete broken HTML.
  - runningdogx 15y ago
    Is it more of an ugly hack than forcing arbitrary sites to https based on a list that's partially hard-coded, partially user-specified, and partially added through an HSTS header in which case the entry also has a limited lifespan? Ugly hacks to make the web even marginally more safe by encouraging or forcing use of https (in places it isn't explicitly specified) may be worthwhile. The thread's chrome hack alone reduces the usability of https, to the point of (I would guess) encouraging sites to use http and disable https so that visitors can actually see embedded content. Average web users know nothing of https, but if they happen across a site using https and embedded content doesn't show up, they'll blame the site. Certainly _that_ is not good. If this google hack is truly worth the pain, and even a small fraction of embedded content works with the uri changed from http to https, that's a benefit because it makes https more usable. Would you think the same about simply changing the HSTS header so that sites could tell a browser to force loading all embedded http:// http:// content through https:// https://? It seems to me like Google's long-term goal is to encourage tls everywhere. If all sites that have user accounts (thus logins) are using https, and all content embedded on those sites has to be referenced over https (or another secure protocol), that's probably the bulk of the web. So the long term costs (in the far future) are an irrelevant cruft of a hack that ends up doing nothing because there are no http:// http:// resource links anywhere. A hack which could, at that point, be removed with no impact whatsoever.
    - gst 15y ago
      HSTS (even with the embedded list) only works if the website operator opts-in. Just one example where your suggestion might break sites: Let's assume a site hosts non-SSL content on www.example.com and SSL content on example.com. Now the site want's to default to SSL by changing most of the links and by automatically redirecting every non-SSL www.example.com request to a SSL secure.example.com. For "traditional" browsers this approach would work fine: Even if non-SSL resources are linked users are redirected to the right place. With the new Chrome approach chrome might block some of the content, but makes it clear why this was done. Users can also override this block (at least for now). With your suggestion this page will break as the browser tries to access the SSL version at www.example.com, which might not exist, or which might not have a correct certificate. Granted, this is just one example, and there are other cases where this approach might work fine. But the Web is just too complex to predict how such hacks will work out. I cannot think of a single such hack that did not create long term problems eventually.
- nitrogen 15y ago
  In addition to the other points mentioned about this not being the browser's responsibility and http/https leading to different places, there's also the potential for swamping servers that can handle their current traffic over http, but would crush under the additional stress caused by encrypting everything.
  - runningdogx 15y ago
    The new Chrome hack forces embeddable content hosting sites (e.g. imageshack) to choose between supporting https, or giving up the analytics data they gain from being embedded on so many pages. It also forces sites with embedded content to implement hacks, converting img and other embed tag uris specified as http into https uris. But if the underlying page is loaded over https, obviously you either want to try getting the resource over https or not at all. What other sane thing is there for a web app to do other than convert all such uris from http to https when serving a page over https? Many uris will break that way, but it's better than not serving any of them. And, if that's the only sane thing for a webapp to do in that situation, why not put that logic into the web browser? As I mentioned in reply to gst, browsers supporting HSTS already have several modes of "force https for a uri specified as http". Adding one more hardly seems like an unacceptably ugly hack. Regardless, embedded content sites that would be swamped if all requests were over https, and sites that map http://foo http://foo and https://foo https://foo differently, are going to have to figure out solutions, or they'll stop being embedded as more sites enable https. Even under the status quo, mixed content warnings and symbols are a little bit scary and sites wishing to go https-enabled or https-only will encourage members to use embeddable content hosting services that support https.
    - nitrogen 15y ago
      I'm all for forcing the web to move forward with technology and security, but I also strongly dislike doing things that result in link rot, etc., particularly on the browser side. It may be that this approach is the best solution, but as yet I'm unconvinced.
dexen 15y ago
That will break the free Google Maps v2 embedded in HTTPS websites (as per http://code.google.com/apis/maps/faq.html#ssl http://code.google.com/apis/maps/faq.html#ssl) That aside, a good move. Seems Chrome team is the first browser team not affraid of stating openly, ``stick to standards and best practices, because we won't be piling hacks upon hacks for compatibility''. Yay :-)
- agl 15y ago
  Credit where credit is due: IE9 beat us to this.
- abraham 15y ago
  Google Maps v2 has been deprecated so sites should update to v3 anyways.
  - kgrin 15y ago
    You know, I'm sympathetic to this point and yet... I can't help feeling like this sort of thing really screws people who put up perfectly serviceable websites just 3 short years ago, who now need to go back and spend effort just to keep things working. It's hard to say if the benefits in this particular case are worth it, but I'm becoming increasingly wary of "this old hotness is deprecated, everyone should upgrade to the new hotness!"
puls 15y ago
Yes please.
callahad 15y ago
This would be fine, if only more third party resources were available over HTTPS at a reasonable cost. For instance, I'd love to use Olark for occasional customer support queries, and the free plan would work great for now. Unfortunately, Olark doesn't offer SSL until their $49/month plan. Similarly, Cloudmade's fantastic OpenStreetMap tileserver is only available over plain HTTP, period. With this change, I would have to choose between great services like Olark or CloudMade and offering SSL everywhere on the site. I understand that select pages with mixed content could be subject to man-in-the-middle attacks, but surely that's a better risk profile than forcing me to run everything over HTTP, right?
- nl 15y ago
  Why is this getting downvoted? It's a huge, common issue. For example, Yahoo's AJAX libraries serve via HTTP, and it doesn't work over HTTPS. See, for example https://yui.yahooapis.com/combo?2.9.0/build/yahoo-dom-event/yahoo-dom-event.js&2.9.0/build/animation/animation-min.js https://yui.yahooapis.com/combo?2.9.0/build/yahoo-dom-event/...
  - xorglorb 15y ago
    Google's CDN has YUI over SSL: http://code.google.com/apis/libraries/devguide.html#yui http://code.google.com/apis/libraries/devguide.html#yui
    - nl 15y ago
      This is true, but doesn't invalidate my point
- stoney 15y ago
  I got around the problem of needing to show data from a non-SSL map server on an https site by using reverse proxying. So my javascript requests the map tiles from a URL on my site (over https), the server then forwards the request to the real map server. That should work for Cloudmade's map server. Not sure if you could do that with Olark.
- 15y ago
ChuckMcM 15y ago
I see mixed http/https in gmail a lot. I wonder if that will break it.
- abraham 15y ago
  That should be from loading images over http which will not trigger the warning.
JoshTriplett 15y ago
This seems like a great step. In the future, I hope to see browsers starting to help sites eliminate third-party scripts entirely. <script src="http://elsewhere/&#62 http://elsewhere/> makes your site's security depend on that of "elsewhere", and allows "elsewhere" to do anything the logged-in user can do; changing the URL to https://elsewhere/ https://elsewhere/ doesn't change that.
- kijinbear 15y ago
  There's no way Chrome will do this until Google can find a different way to insert AdSense ads on third-party sites. Currently, third-party scripts are the best way to achieve this. iframes are inelegant, and telling webmasters to update the script every once in a while just isn't going to work. But I do hope that something like this becomes one of the standard add-ons that we can install. I'll have to go check if NoScript has a similar option...
  - JoshTriplett 15y ago
    What makes an iframe inelegant? It seems like the correct way to handle advertisements or other third-party content.
- spoondan 15y ago
  The browsers aren't going to be disallowing CDNs any time soon.
nl 15y ago
Am I alone in questioning this? I'm all for serving anything requiring logins over HTTPS, and can accept the argument for anything requiring cookies. But what about the performance improvements available by using shared, cached CDN resources? That doesn't really work over HTTPS, and the performance impact of missing out on that is substantial. There are other cases too: I think it often makes sense to serve static content (eg images) via HTTP while having the HTML on HTTPS. Why should the browser block (or even alert) about this?
- lamby 15y ago
  > But what about the performance improvements available by using shared, cached CDN resources? That doesn't really work over HTTPS, and the performance impact of missing out on that is substantial. SSL resources are still cached, not sure what you're getting at. > it often makes sense to serve static content (eg images) via HTTP while having the HTML on HTTPS. Why should the browser block (or even alert) about this? I MITM your users and insert a huge image saying "You need to confirm your bank account details, please call this number now <insert my phone number>" (etc.)
  - nl 15y ago
    SSL resources are still cached, not sure what you're getting at. Not unless they have the cache-control:public header.
bane 15y ago
I'm still miffed at the chrome team for killing the rendering of local XML files.
- abraham 15y ago
  What are you talking about? Chrome renders XML just fine.
bazookaBen 15y ago
how will this affect facebook iframe apps? They load from a different origin, and the user is bound to receive a cross-domain error. normally, the following would pass: Unsafe JavaScript attempt to access frame with URL http://apps.facebook.com/my_app http://apps.facebook.com/my_app from frame with URL http://server-hosting-my-app.com http://server-hosting-my-app.com. Domains, protocols and ports must match. will this blocked by Chrome in the future? if so, everyone running Chrome 14 onwards won't be able to play Farmville. more info: if you load Farmville on Chrome, this comes up in the debug console (which still passes) Unsafe JavaScript attempt to access frame with URL http://apps.facebook.com/cityville/?installed=1 http://apps.facebook.com/cityville/?installed=1 from frame with URL http://fb-0.cityville.zynga.com/flash.php?isOuterIframe=1&installed=1&[MORE http://fb-0.cityville.zynga.com/flash.php?isOuterIframe=1&#3... INFO HERE CUT OUT]. Domains, protocols and ports must match.
- andrewf 15y ago
  Unsafe JavaScript attempt to access frame with URL http://apps.facebook.com/cityville/?installed=1 http://apps.facebook.com/cityville/?installed=1 from frame with URL http://fb-0.cityville.zynga.com/flash.php?isOuterIframe=1.. http://fb-0.cityville.zynga.com/flash.php?isOuterIframe=1... INFO HERE CUT OUT]. Domains, protocols and ports must match. That's always popped up in WebKit debuggers. I think everyone that's ever developed a Facebook app wastes 20 minutes learning that they can and should ignore it.
- abraham 15y ago
  Starting in October all Facebook canvas apps are required to support SSL https://developers.facebook.com/blog/post/497 https://developers.facebook.com/blog/post/497
nkassis 15y ago
Well they already managed to get me to fixed one of those issues with their announcement ;p I had an embedded youtube video using http on an encrypted site. Just fixed it. But this could break a lot of sites.

48 points by abraham 15y ago

deleted 15y ago

[deleted]

Awesome, looks like a good idea to me! It should also not be very destructive as most legitimate websites already try to eradicate mixed (secure|insecure) content.

runningdogx 15y ago

In an https page, why not rewrite http resources to https by default? Then it could omit the content if there is a cert error or if there is no ssl server there at all. I'm thinking of a use case of a typical not-ssl-mandatory online forum/wiki/whatever. There are going to be tons of historical img and script tags, either to local content or to other sites, that do not use https even when they could; when those links were set up years ago very few sites (other than ecommerce) took ssl seriously. The solutions are going through and changing links in the database, rewriting links in the app, or rewriting links in the web browser. Is there a compelling reason why rewriting links in the web browser is bad? There are five web browsers that people care about: Chrome, FF, IE, Safari, Opera (mostly mobile). There are thousands of webapps and at least tens of thousands of moderately popular sites that would have to rewrite content in the database or webapp in order to go ssl-only.

bonzoesc 15y ago
In a shared hosting environment, http and https might go to entirely different sites.
- falcolas 15y ago
  As well as any content hosted on a CDN.
gst 15y ago
Yes there is a compelling reason: It's not the task of the browser to do this. With such an ugly hack you gain some short term benefits at large long term costs. I guess about 15 years ago someone asked: "Why not let the browser try to interpret broken HTML instead of showing an error page?". The result is today's security nightmare, where it's impossible to reliable prevent script injection into HTML pages, because you can't just block the "official" way to insert a script, but also need to look into each of those ways how an HTML engine might interprete broken HTML.
- runningdogx 15y ago
  Is it more of an ugly hack than forcing arbitrary sites to https based on a list that's partially hard-coded, partially user-specified, and partially added through an HSTS header in which case the entry also has a limited lifespan? Ugly hacks to make the web even marginally more safe by encouraging or forcing use of https (in places it isn't explicitly specified) may be worthwhile. The thread's chrome hack alone reduces the usability of https, to the point of (I would guess) encouraging sites to use http and disable https so that visitors can actually see embedded content. Average web users know nothing of https, but if they happen across a site using https and embedded content doesn't show up, they'll blame the site. Certainly _that_ is not good. If this google hack is truly worth the pain, and even a small fraction of embedded content works with the uri changed from http to https, that's a benefit because it makes https more usable. Would you think the same about simply changing the HSTS header so that sites could tell a browser to force loading all embedded http:// http:// content through https:// https://? It seems to me like Google's long-term goal is to encourage tls everywhere. If all sites that have user accounts (thus logins) are using https, and all content embedded on those sites has to be referenced over https (or another secure protocol), that's probably the bulk of the web. So the long term costs (in the far future) are an irrelevant cruft of a hack that ends up doing nothing because there are no http:// http:// resource links anywhere. A hack which could, at that point, be removed with no impact whatsoever.
  - gst 15y ago
    HSTS (even with the embedded list) only works if the website operator opts-in. Just one example where your suggestion might break sites: Let's assume a site hosts non-SSL content on www.example.com and SSL content on example.com. Now the site want's to default to SSL by changing most of the links and by automatically redirecting every non-SSL www.example.com request to a SSL secure.example.com. For "traditional" browsers this approach would work fine: Even if non-SSL resources are linked users are redirected to the right place. With the new Chrome approach chrome might block some of the content, but makes it clear why this was done. Users can also override this block (at least for now). With your suggestion this page will break as the browser tries to access the SSL version at www.example.com, which might not exist, or which might not have a correct certificate. Granted, this is just one example, and there are other cases where this approach might work fine. But the Web is just too complex to predict how such hacks will work out. I cannot think of a single such hack that did not create long term problems eventually.
nitrogen 15y ago
In addition to the other points mentioned about this not being the browser's responsibility and http/https leading to different places, there's also the potential for swamping servers that can handle their current traffic over http, but would crush under the additional stress caused by encrypting everything.
- runningdogx 15y ago
  The new Chrome hack forces embeddable content hosting sites (e.g. imageshack) to choose between supporting https, or giving up the analytics data they gain from being embedded on so many pages. It also forces sites with embedded content to implement hacks, converting img and other embed tag uris specified as http into https uris. But if the underlying page is loaded over https, obviously you either want to try getting the resource over https or not at all. What other sane thing is there for a web app to do other than convert all such uris from http to https when serving a page over https? Many uris will break that way, but it's better than not serving any of them. And, if that's the only sane thing for a webapp to do in that situation, why not put that logic into the web browser? As I mentioned in reply to gst, browsers supporting HSTS already have several modes of "force https for a uri specified as http". Adding one more hardly seems like an unacceptably ugly hack. Regardless, embedded content sites that would be swamped if all requests were over https, and sites that map http://foo http://foo and https://foo https://foo differently, are going to have to figure out solutions, or they'll stop being embedded as more sites enable https. Even under the status quo, mixed content warnings and symbols are a little bit scary and sites wishing to go https-enabled or https-only will encourage members to use embeddable content hosting services that support https.
  - nitrogen 15y ago
    I'm all for forcing the web to move forward with technology and security, but I also strongly dislike doing things that result in link rot, etc., particularly on the browser side. It may be that this approach is the best solution, but as yet I'm unconvinced.

dexen 15y ago

That will break the free Google Maps v2 embedded in HTTPS websites (as per http://code.google.com/apis/maps/faq.html#ssl http://code.google.com/apis/maps/faq.html#ssl) That aside, a good move. Seems Chrome team is the first browser team not affraid of stating openly, ``stick to standards and best practices, because we won't be piling hacks upon hacks for compatibility''. Yay :-)

agl 15y ago
Credit where credit is due: IE9 beat us to this.
abraham 15y ago
Google Maps v2 has been deprecated so sites should update to v3 anyways.
- kgrin 15y ago
  You know, I'm sympathetic to this point and yet... I can't help feeling like this sort of thing really screws people who put up perfectly serviceable websites just 3 short years ago, who now need to go back and spend effort just to keep things working. It's hard to say if the benefits in this particular case are worth it, but I'm becoming increasingly wary of "this old hotness is deprecated, everyone should upgrade to the new hotness!"

puls 15y ago

Yes please.

callahad 15y ago

This would be fine, if only more third party resources were available over HTTPS at a reasonable cost. For instance, I'd love to use Olark for occasional customer support queries, and the free plan would work great for now. Unfortunately, Olark doesn't offer SSL until their $49/month plan. Similarly, Cloudmade's fantastic OpenStreetMap tileserver is only available over plain HTTP, period. With this change, I would have to choose between great services like Olark or CloudMade and offering SSL everywhere on the site. I understand that select pages with mixed content could be subject to man-in-the-middle attacks, but surely that's a better risk profile than forcing me to run everything over HTTP, right?

nl 15y ago
Why is this getting downvoted? It's a huge, common issue. For example, Yahoo's AJAX libraries serve via HTTP, and it doesn't work over HTTPS. See, for example https://yui.yahooapis.com/combo?2.9.0/build/yahoo-dom-event/yahoo-dom-event.js&2.9.0/build/animation/animation-min.js https://yui.yahooapis.com/combo?2.9.0/build/yahoo-dom-event/...
- xorglorb 15y ago
  Google's CDN has YUI over SSL: http://code.google.com/apis/libraries/devguide.html#yui http://code.google.com/apis/libraries/devguide.html#yui
  - nl 15y ago
    This is true, but doesn't invalidate my point
stoney 15y ago
I got around the problem of needing to show data from a non-SSL map server on an https site by using reverse proxying. So my javascript requests the map tiles from a URL on my site (over https), the server then forwards the request to the real map server. That should work for Cloudmade's map server. Not sure if you could do that with Olark.
15y ago

ChuckMcM 15y ago

I see mixed http/https in gmail a lot. I wonder if that will break it.

abraham 15y ago
That should be from loading images over http which will not trigger the warning.

JoshTriplett 15y ago

This seems like a great step. In the future, I hope to see browsers starting to help sites eliminate third-party scripts entirely. <script src="http://elsewhere/&#62 http://elsewhere/> makes your site's security depend on that of "elsewhere", and allows "elsewhere" to do anything the logged-in user can do; changing the URL to https://elsewhere/ https://elsewhere/ doesn't change that.

kijinbear 15y ago
There's no way Chrome will do this until Google can find a different way to insert AdSense ads on third-party sites. Currently, third-party scripts are the best way to achieve this. iframes are inelegant, and telling webmasters to update the script every once in a while just isn't going to work. But I do hope that something like this becomes one of the standard add-ons that we can install. I'll have to go check if NoScript has a similar option...
- JoshTriplett 15y ago
  What makes an iframe inelegant? It seems like the correct way to handle advertisements or other third-party content.
spoondan 15y ago
The browsers aren't going to be disallowing CDNs any time soon.

nl 15y ago

Am I alone in questioning this? I'm all for serving anything requiring logins over HTTPS, and can accept the argument for anything requiring cookies. But what about the performance improvements available by using shared, cached CDN resources? That doesn't really work over HTTPS, and the performance impact of missing out on that is substantial. There are other cases too: I think it often makes sense to serve static content (eg images) via HTTP while having the HTML on HTTPS. Why should the browser block (or even alert) about this?

lamby 15y ago
> But what about the performance improvements available by using shared, cached CDN resources? That doesn't really work over HTTPS, and the performance impact of missing out on that is substantial. SSL resources are still cached, not sure what you're getting at. > it often makes sense to serve static content (eg images) via HTTP while having the HTML on HTTPS. Why should the browser block (or even alert) about this? I MITM your users and insert a huge image saying "You need to confirm your bank account details, please call this number now <insert my phone number>" (etc.)
- nl 15y ago
  SSL resources are still cached, not sure what you're getting at. Not unless they have the cache-control:public header.

bane 15y ago

I'm still miffed at the chrome team for killing the rendering of local XML files.

abraham 15y ago
What are you talking about? Chrome renders XML just fine.

bazookaBen 15y ago

how will this affect facebook iframe apps? They load from a different origin, and the user is bound to receive a cross-domain error. normally, the following would pass: Unsafe JavaScript attempt to access frame with URL http://apps.facebook.com/my_app http://apps.facebook.com/my_app from frame with URL http://server-hosting-my-app.com http://server-hosting-my-app.com. Domains, protocols and ports must match. will this blocked by Chrome in the future? if so, everyone running Chrome 14 onwards won't be able to play Farmville. more info: if you load Farmville on Chrome, this comes up in the debug console (which still passes) Unsafe JavaScript attempt to access frame with URL http://apps.facebook.com/cityville/?installed=1 http://apps.facebook.com/cityville/?installed=1 from frame with URL http://fb-0.cityville.zynga.com/flash.php?isOuterIframe=1&installed=1&[MORE http://fb-0.cityville.zynga.com/flash.php?isOuterIframe=1&#3... INFO HERE CUT OUT]. Domains, protocols and ports must match.

andrewf 15y ago
Unsafe JavaScript attempt to access frame with URL http://apps.facebook.com/cityville/?installed=1 http://apps.facebook.com/cityville/?installed=1 from frame with URL http://fb-0.cityville.zynga.com/flash.php?isOuterIframe=1.. http://fb-0.cityville.zynga.com/flash.php?isOuterIframe=1... INFO HERE CUT OUT]. Domains, protocols and ports must match. That's always popped up in WebKit debuggers. I think everyone that's ever developed a Facebook app wastes 20 minutes learning that they can and should ignore it.
abraham 15y ago
Starting in October all Facebook canvas apps are required to support SSL https://developers.facebook.com/blog/post/497 https://developers.facebook.com/blog/post/497

nkassis 15y ago

Well they already managed to get me to fixed one of those issues with their announcement ;p I had an embedded youtube video using http on an encrypted site. Just fixed it. But this could break a lot of sites.