41–50 of 143 posts
So- to the HN community, is this whole "ssl is cheap" a false meme, or does someone have actual instructions on how to deploy & implement a scalable SSL?
Earlier quoted context omitted.
> 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.
1. Include 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.
While sites wait for services such as adsense to support SSL, adding a second Secure cookie and requiring on sensitive pages and to perform destructive actions can help reduce risk to users. Depending on the site, it may be OK to skip showing ads on a few authenticated pages. Wordpress implemented this in 2008: http://ryan.boren.me/2008/07/14/ssl-and-cookies-in-wordpress... This won't protect against active attackers…
1) Lose the ajax (and spend a significant time redoing bits of the site) 2) Scary iframe hacks. 3) SSL Everywhere.
I feel like we made the best choice (I certainly don't mind removing any chance we'll have adsense any time soon :). It cleaned up a lot of logic based around determining which pages were important enough to require SSL (admin functions, private repos, etc).
It's brought on some other issues though. Safari and Chrome don't seem to properly cache HTTPS assets to disk, for one. This is an old problem: http://37signals.com/svn/posts/1431-mixed-content-warning-ho... . I'm not too worried about increased bandwidth bills on our end, I'm worried about having a slower site experience. We're also seeing users complain about having to log in every day. Are browsers not keeping secure cookies around either?
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…
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.
Earlier quoted context omitted.
1. Include 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.
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.
Earlier quoted context omitted.
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. Whil…
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…
> I agree with you that we need some good free CAs
https://www.startssl.com/ Supported by just about every browser. Entirely free. A fellow Hacker News user linked to it in a similar thread. I was impressed :)
Earlier quoted context omitted.
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.
Thats why I use IE6. No tabs, no problem.
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…
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.
http://groups.google.com/group/google-chart-api/msg/85186f74...
Earlier quoted context omitted.
> 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.
1. Include 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.
It certainly might be possible for the attacker to compromise a specific server that you have chosen to trust - but that's a much higher barrier to an attacker than performing MITM on an open Wifi connection which doesn't require them to compromise any server.
Earlier quoted context omitted.
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.
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/85186f74...