8 ms·

This is a problem we (GitHub) are facing in a big way right now. Google Charts doesn't offer https alternatives, so almost all our users get a big "this site is

by kneath 16y ago

This is a problem we (GitHub) are facing in a big way right now. Google Charts doesn't offer https alternatives, so almost all our users get a big "this site is going to steal all your private information" (mixed content warning). We chose to roll out SSL first, then deal with the hard problem of mixed content warnings (building ridiculous image proxies) later. I think a lot of developers underestimate how big of an impact this warning is on users, especially on browsers like IE that throw up a dialog on every page that has this warning. Developers understand that it's not that big of a deal — but to a user, it looks like the site is full of viruses, malware and is going to steal all your bank account information.

ericflo 16y ago
Not only that, but in IE it's a modal dialog. You can't do anything (even switch to another tab) until you've acknowledged the scary warning.
- templaedhel 16y ago
  Thats why I use IE6. No tabs, no problem.
  - SoftwareMaven 16y ago
    It's good to have a solid reason to keep IE6 around. I'd hate for it to go away!
ryanto 16y ago
Yup, I agree with you. This is a pretty big problem with a lot of other google services as well. The google maps api for example will not work behind https. Google has publicly said that this is because they want their maps free and open, not behind some page where the user needs to be logged in. This create a huge problem for any site that uses google maps. They do offer a solution though, for $10,000 a year they will let you use the map api behind https.
- thadk 16y ago
  For reference, this 2009 post talks about how you need to subscribe to $10,000 Google Maps API Premier to use Google Maps on a private service: http://47hats.com/2009/07/google-maps-the-10k-gotcha/ http://47hats.com/2009/07/google-maps-the-10k-gotcha/ http://www.google.com/enterprise/earthmaps/maps.html http://www.google.com/enterprise/earthmaps/maps.html
Udo 16y ago
Exactly. Browser makers (including Mozilla/Firefox to a large degree) are responsible for the fact that HTTPS hasn't become the standard protocol as it should have been years ago. It's not only the unproductive mixed content warning but also the insistence of all browsers to only accept expensively bought certificates and throw a very scary and hard to overcome error dialog if a site uses any other kind of cert. While that isn't a problem for big(gish) commercial sites like GitHub, it presents an insurmountable hurdle for private sites and small-time projects for no good reason. For most sites I don't need "secure" origin verification as badly as encryption. The lack of a verifiable server address shouldn't mean that I should be bullied to not use an encrypted connection with it. But even if the verdict is that you absolutely can't have one without the other, browser makers should AT LEAST include trusted root certs of authorities who offer free SSL certificates, too.
- al_james 16y ago
  Hmmm... I see what you are saying, but (for example) godaddy offer basic SSL certs for $10. Not a huge price for anyone.
- kijinbear 16y ago
  While your frustration is understandable, I think you're speaking from the perspective of a tech-savvy person and not the average user. If browsers began accepting all free / self-signed certificates, it would be only a matter of time before something like "Firesheep FX" came along and permitted random strangers to MITM anybody's SSL session. Some of us can notice when that happens, but most people won't have a clue unless the browser presented them with a big scary red warning. However, I agree with you that we need some good free CAs. The difference between free and $10/year is bigger than most of us think it is. Fortunately, there are registrars such as Gandi which will give you free certificates with every domain.
  - Udo 16y ago
    > If browsers began accepting all free / self-signed certificates [...] Right now, browsers are accepting any unencrypted old HTTP connection without any warning, while non-verified securely encrypted connections are actively prevented. Tech people can circumvent the block, but normal users cannot. Nor do they have any reason to because the warning they are being shown sounds like the end of the world, while any unsecured connection looks perfectly fine to them. This is something that could be done right now to make everybody more secure, at no cost, but it threatens the business model of companies like Verisign. Nobody is suggesting that browser makers should display the much-sought-after "lock of absolute protection" icon on any random SSL connection, I'd be fine if they reserve that for paid-for-certs. I'm merely suggesting they show free (or even self-signed) certs the same courtesy as basic HTTP, the most permissive protocol of all time, instead of actively preventing users from using encryption. I agree with you about the threat of "Firesheep FX" and believe Wifi connections should probably all use WPA2, even at coffee shops where internet access is free. The threat of MITM is real, but the attack can be made more difficult using a number of schemes, and it even includes free certs that offer way more protection than any unencrypted link ever could. Yet, we are currently encouraging unencrypted connections while actively blocking encrypted ones. If HTTPS could have the same UI mechanisms as, say, an SSH connection I'm convinced the online world would be a much safer place.
mickeyben 16y ago
We discovered the exact same issue and rolled back few weeks ago. The worst is that the default selected choice in the modal box is to not load anything.
- zmmmmm 16y ago
  The IE8 warning is the most confusing sentence I've ever seen. Even I as a veteran of 13 years of web programming have to read that thing 3 times to know which button to press to make it load the damned stuff.
swolchok 16y ago
The warning isn't spurious, by the way. A man in the middle could inject evil JS into urchin.js (or whatever the equivalent is now) just as easily as he could inject it into your site's JS; the page is not secure.
- kneath 16y ago
  Indeed, the warning has it's merits. That being said the second part of your argument is completely wrong. You can just as easily inject evil JS using an https server and never get the mixed content warnings. The warning serves to indicate to users that some assets (think important-financial-graph.jpg) aren't being served over the same encryption as the rest of the page. But then again, browsers like Safari have no problem with this. Other browsers like Firefox (correctly) cache these assets on disk if Cache-Control:public is set, thereby un-encrypting the asset. The error may not be spurious, but it sure doesn't mean the page is secure or not.
  - chrisbroadfoot 16y ago
    > You can just as easily inject evil JS using an https server and never get the mixed content warnings. Only if the user ignores the "invalid certificate" warning.
    - kneath 16y ago
      1. Include https://hot-new-metrics-startup.com/tracker.js https://hot-new-metrics-startup.com/tracker.js 2. hot-new-metrics-startup gets hacked. Sends over malicious js 3. Your page is no longer secure. https certificate remains. We can argue semantics, but I guess I'm more concerned about the end result than semantics.
      - djcapelis 16y ago
        Absolutely, but the protection SSL helps with is it actually forces the attacker to compromise hot-new-metrics whereas without SSL you can just skip the first part of step 2 and just do "send malicious js" through a MITM without ever having to go compromise any of the services involved.
NiekvdMaas 16y ago
For Google Charts, there is a workaround. Simply change the hostname to www.google.com, example: http://chart.apis.google.com/chart?chs=200x200&cht=qr&chl=http://www.adperium.com/ (normal) https://www.google.com/chart?chs=200x200&cht=qr&chl=http://www.adperium.com/ (HTTPS) It's probably not what Google prefers, but this works for us.
- jbyers 16y ago
  It does work and Google definitely does not want the public to use it. A Googler's post on the topic from 2007: http://groups.google.com/group/google-chart-api/msg/85186f740c2a09dd http://groups.google.com/group/google-chart-api/msg/85186f74...
  - nikcub 16y ago
    In writing a plugin that rewrites URLs as https (http://github.com/nikcub/fidelio http://github.com/nikcub/fidelio) I found that this worked in a lot of places. Facebook does not explicitly support ssl everywhere, but you can rewrite the requests to https servers and it works.
tomjen3 16y ago
Couldn't you just cache the charts locally, and then serve them directly to the user?
thwarted 16y ago
During the last Velocity conference, one of the last sessions on the last day was a talk from Google guys about how to make SSL faster, because they had recently turned SSL on for all gmail accounts. I asked how they deal with the unlocked icon and warning dialogs for mixed protocol content on the page and the response was that people are so used to the popups and the lock being unlocked, that they (Google) don't consider it to be a problem. The response was really short and curt and I felt it was kind of a cop-out.
- mambodog 16y ago
  Maybe they feel like its not a problem for them because average users trust them without a second thought.
  - thwarted 16y ago
    I suppose; unfortunately, the talk was in the context of making the same kinds of changes to your, or any random, site to make it more feasible to use SSL. Also unfortunately, when there is mixed protocol content, especially with email, you're not asserting trust of the page origin, but of the additional assets loaded. Google has no control over the content referenced in emails. Encouraging people to ignore the warnings doesn't make anyone safer, if people are not informed enough to care or not. One of the suggestions was to use shorter key lengths to make SSL less expensive to process, this wasn't considered a welcome suggestion by many of the more security conscious and vocal folks in the room.
- agl 16y ago
  Well, as I recall, several of the questioners at that session were verging on the point of heckling, so many of the responses were short. But the answer is that permitting mixed content was probably a mistake in the first place, but it's one that we have to live with. The ease of mixing content means that many sites get it wrong (including Google sites, to our shame) and the lack of ubiquitous SSL (again, including some Google sites) imposes that on others. So, I suppose that `we don't consider it a problem' is roughly correct regarding warning dialogs: the answer is not to mix content. The problem is that it's clearly too difficult to do that. (The inability of networks to cache public resources over HTTPS is also an issue and possibly one which we'll address.) Lack of SSL on the Chart's API is a new one, but I'll look into it now that I know that it's a problem. As for the rest of the problem: fixing stuff is hard. Miraculous answers invariably tend to be so only in the eyes of the conceiver. We'll keep plugging away.
drivebyacct2 16y ago
Could you proxy through your own servers?
- kaitnieks 16y ago
  This is problematic with services that have limits such as maximum connections per day from a single IP
tommorris 16y ago
Is there a lot of GitHub users using IE? ;-)
notphilatall 16y ago
How about: Give every user a monotonically incrementing value that's initialized at the start of the session using HTTPS. For every request, the client will provide the next value in the expected sequence. Listeners won't have the secret key that was exchanged during the HTTPS authentication, and can't issue requests on the legitimate client's behalf. Forcing the requests to be serial sucks, but if you only do it for privileged actions (as opposed to public page GETs) it should be manageable.
- zbanks 16y ago
  Still vernerable to MITM attacks, since an attacker could intercept a legitimate respo se for safe.js, but then send the user a completely different file. You need to sign the entire file. Now you're incredibly close to having SSL.
aschobel 16y ago
We had to disable support for Google Maps on Catch.com because the costs was too prohibitive to use their "enterprise" SSL enabled version. It's a damn shame because it was a really cool integration.
patio11 16y ago
This is a problem we (GitHub) are facing in a big way right now This also broke Bingo Card Creator something fierce when I rolled out SSL support. It was the reason I hadn't had it previously, and I knew it was going to be a problem going in, and I tested for it, and I still managed to hose two pages which were critical to my business for most of a week. Figure on a 40~50% drop in conversion from a non-technical audience on IE if they get one of those popups, by the way. It is the worst possible place to be: not enough to trigger an automated "Oh cripes!" from the website, but big enough to murder business results.
ansonparker 16y ago
Absolutely. I have run an SSL-only site (https://domize.com https://domize.com) for a few years now. Other than Google Analytics I can't think of a single other widget/embed/analytics app that has supported SSL out of the box. It's a real shame, but on the other hand I'd bet good money that the web will be 99% SSL within the next 24 months.
ntoshev 16y ago
The image proxy won't work: Google's js APIs are throttled per IP to prevent abuse.
deleted 16y ago
[deleted]

by kneath 16y ago

ericflo 16y ago

Not only that, but in IE it's a modal dialog. You can't do anything (even switch to another tab) until you've acknowledged the scary warning.

templaedhel 16y ago
Thats why I use IE6. No tabs, no problem.
- SoftwareMaven 16y ago
  It's good to have a solid reason to keep IE6 around. I'd hate for it to go away!

ryanto 16y ago

Yup, I agree with you. This is a pretty big problem with a lot of other google services as well. The google maps api for example will not work behind https. Google has publicly said that this is because they want their maps free and open, not behind some page where the user needs to be logged in. This create a huge problem for any site that uses google maps. They do offer a solution though, for $10,000 a year they will let you use the map api behind https.

thadk 16y ago
For reference, this 2009 post talks about how you need to subscribe to $10,000 Google Maps API Premier to use Google Maps on a private service: http://47hats.com/2009/07/google-maps-the-10k-gotcha/ http://47hats.com/2009/07/google-maps-the-10k-gotcha/ http://www.google.com/enterprise/earthmaps/maps.html http://www.google.com/enterprise/earthmaps/maps.html

Udo 16y ago

Exactly. Browser makers (including Mozilla/Firefox to a large degree) are responsible for the fact that HTTPS hasn't become the standard protocol as it should have been years ago. It's not only the unproductive mixed content warning but also the insistence of all browsers to only accept expensively bought certificates and throw a very scary and hard to overcome error dialog if a site uses any other kind of cert. While that isn't a problem for big(gish) commercial sites like GitHub, it presents an insurmountable hurdle for private sites and small-time projects for no good reason. For most sites I don't need "secure" origin verification as badly as encryption. The lack of a verifiable server address shouldn't mean that I should be bullied to not use an encrypted connection with it. But even if the verdict is that you absolutely can't have one without the other, browser makers should AT LEAST include trusted root certs of authorities who offer free SSL certificates, too.

al_james 16y ago
Hmmm... I see what you are saying, but (for example) godaddy offer basic SSL certs for $10. Not a huge price for anyone.
kijinbear 16y ago
While your frustration is understandable, I think you're speaking from the perspective of a tech-savvy person and not the average user. If browsers began accepting all free / self-signed certificates, it would be only a matter of time before something like "Firesheep FX" came along and permitted random strangers to MITM anybody's SSL session. Some of us can notice when that happens, but most people won't have a clue unless the browser presented them with a big scary red warning. However, I agree with you that we need some good free CAs. The difference between free and $10/year is bigger than most of us think it is. Fortunately, there are registrars such as Gandi which will give you free certificates with every domain.
- Udo 16y ago
  > If browsers began accepting all free / self-signed certificates [...] Right now, browsers are accepting any unencrypted old HTTP connection without any warning, while non-verified securely encrypted connections are actively prevented. Tech people can circumvent the block, but normal users cannot. Nor do they have any reason to because the warning they are being shown sounds like the end of the world, while any unsecured connection looks perfectly fine to them. This is something that could be done right now to make everybody more secure, at no cost, but it threatens the business model of companies like Verisign. Nobody is suggesting that browser makers should display the much-sought-after "lock of absolute protection" icon on any random SSL connection, I'd be fine if they reserve that for paid-for-certs. I'm merely suggesting they show free (or even self-signed) certs the same courtesy as basic HTTP, the most permissive protocol of all time, instead of actively preventing users from using encryption. I agree with you about the threat of "Firesheep FX" and believe Wifi connections should probably all use WPA2, even at coffee shops where internet access is free. The threat of MITM is real, but the attack can be made more difficult using a number of schemes, and it even includes free certs that offer way more protection than any unencrypted link ever could. Yet, we are currently encouraging unencrypted connections while actively blocking encrypted ones. If HTTPS could have the same UI mechanisms as, say, an SSH connection I'm convinced the online world would be a much safer place.

mickeyben 16y ago

We discovered the exact same issue and rolled back few weeks ago. The worst is that the default selected choice in the modal box is to not load anything.

zmmmmm 16y ago
The IE8 warning is the most confusing sentence I've ever seen. Even I as a veteran of 13 years of web programming have to read that thing 3 times to know which button to press to make it load the damned stuff.

swolchok 16y ago

The warning isn't spurious, by the way. A man in the middle could inject evil JS into urchin.js (or whatever the equivalent is now) just as easily as he could inject it into your site's JS; the page is not secure.

kneath 16y ago
Indeed, the warning has it's merits. That being said the second part of your argument is completely wrong. You can just as easily inject evil JS using an https server and never get the mixed content warnings. The warning serves to indicate to users that some assets (think important-financial-graph.jpg) aren't being served over the same encryption as the rest of the page. But then again, browsers like Safari have no problem with this. Other browsers like Firefox (correctly) cache these assets on disk if Cache-Control:public is set, thereby un-encrypting the asset. The error may not be spurious, but it sure doesn't mean the page is secure or not.
- chrisbroadfoot 16y ago
  > You can just as easily inject evil JS using an https server and never get the mixed content warnings. Only if the user ignores the "invalid certificate" warning.
  - kneath 16y ago
    1. Include https://hot-new-metrics-startup.com/tracker.js https://hot-new-metrics-startup.com/tracker.js 2. hot-new-metrics-startup gets hacked. Sends over malicious js 3. Your page is no longer secure. https certificate remains. We can argue semantics, but I guess I'm more concerned about the end result than semantics.
    - djcapelis 16y ago
      Absolutely, but the protection SSL helps with is it actually forces the attacker to compromise hot-new-metrics whereas without SSL you can just skip the first part of step 2 and just do "send malicious js" through a MITM without ever having to go compromise any of the services involved.

NiekvdMaas 16y ago

For Google Charts, there is a workaround. Simply change the hostname to www.google.com, example: http://chart.apis.google.com/chart?chs=200x200&cht=qr&chl=http://www.adperium.com/ (normal) https://www.google.com/chart?chs=200x200&cht=qr&chl=http://www.adperium.com/ (HTTPS) It's probably not what Google prefers, but this works for us.

jbyers 16y ago
It does work and Google definitely does not want the public to use it. A Googler's post on the topic from 2007: http://groups.google.com/group/google-chart-api/msg/85186f740c2a09dd http://groups.google.com/group/google-chart-api/msg/85186f74...
- nikcub 16y ago
  In writing a plugin that rewrites URLs as https (http://github.com/nikcub/fidelio http://github.com/nikcub/fidelio) I found that this worked in a lot of places. Facebook does not explicitly support ssl everywhere, but you can rewrite the requests to https servers and it works.

tomjen3 16y ago

Couldn't you just cache the charts locally, and then serve them directly to the user?

thwarted 16y ago

During the last Velocity conference, one of the last sessions on the last day was a talk from Google guys about how to make SSL faster, because they had recently turned SSL on for all gmail accounts. I asked how they deal with the unlocked icon and warning dialogs for mixed protocol content on the page and the response was that people are so used to the popups and the lock being unlocked, that they (Google) don't consider it to be a problem. The response was really short and curt and I felt it was kind of a cop-out.

mambodog 16y ago
Maybe they feel like its not a problem for them because average users trust them without a second thought.
- thwarted 16y ago
  I suppose; unfortunately, the talk was in the context of making the same kinds of changes to your, or any random, site to make it more feasible to use SSL. Also unfortunately, when there is mixed protocol content, especially with email, you're not asserting trust of the page origin, but of the additional assets loaded. Google has no control over the content referenced in emails. Encouraging people to ignore the warnings doesn't make anyone safer, if people are not informed enough to care or not. One of the suggestions was to use shorter key lengths to make SSL less expensive to process, this wasn't considered a welcome suggestion by many of the more security conscious and vocal folks in the room.
agl 16y ago
Well, as I recall, several of the questioners at that session were verging on the point of heckling, so many of the responses were short. But the answer is that permitting mixed content was probably a mistake in the first place, but it's one that we have to live with. The ease of mixing content means that many sites get it wrong (including Google sites, to our shame) and the lack of ubiquitous SSL (again, including some Google sites) imposes that on others. So, I suppose that `we don't consider it a problem' is roughly correct regarding warning dialogs: the answer is not to mix content. The problem is that it's clearly too difficult to do that. (The inability of networks to cache public resources over HTTPS is also an issue and possibly one which we'll address.) Lack of SSL on the Chart's API is a new one, but I'll look into it now that I know that it's a problem. As for the rest of the problem: fixing stuff is hard. Miraculous answers invariably tend to be so only in the eyes of the conceiver. We'll keep plugging away.

drivebyacct2 16y ago

Could you proxy through your own servers?

kaitnieks 16y ago
This is problematic with services that have limits such as maximum connections per day from a single IP

tommorris 16y ago

Is there a lot of GitHub users using IE? ;-)

notphilatall 16y ago

How about: Give every user a monotonically incrementing value that's initialized at the start of the session using HTTPS. For every request, the client will provide the next value in the expected sequence. Listeners won't have the secret key that was exchanged during the HTTPS authentication, and can't issue requests on the legitimate client's behalf. Forcing the requests to be serial sucks, but if you only do it for privileged actions (as opposed to public page GETs) it should be manageable.

zbanks 16y ago
Still vernerable to MITM attacks, since an attacker could intercept a legitimate respo se for safe.js, but then send the user a completely different file. You need to sign the entire file. Now you're incredibly close to having SSL.

aschobel 16y ago

We had to disable support for Google Maps on Catch.com because the costs was too prohibitive to use their "enterprise" SSL enabled version. It's a damn shame because it was a really cool integration.

patio11 16y ago

This is a problem we (GitHub) are facing in a big way right now This also broke Bingo Card Creator something fierce when I rolled out SSL support. It was the reason I hadn't had it previously, and I knew it was going to be a problem going in, and I tested for it, and I still managed to hose two pages which were critical to my business for most of a week. Figure on a 40~50% drop in conversion from a non-technical audience on IE if they get one of those popups, by the way. It is the worst possible place to be: not enough to trigger an automated "Oh cripes!" from the website, but big enough to murder business results.

ansonparker 16y ago

Absolutely. I have run an SSL-only site (https://domize.com https://domize.com) for a few years now. Other than Google Analytics I can't think of a single other widget/embed/analytics app that has supported SSL out of the box. It's a real shame, but on the other hand I'd bet good money that the web will be 99% SSL within the next 24 months.

ntoshev 16y ago

The image proxy won't work: Google's js APIs are throttled per IP to prevent abuse.

deleted 16y ago

[deleted]