3 ms·

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 ther

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.

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.