4 ms·

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

by 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.
    - kneath 16y ago
      Unless they're using Safari which doesn't have a mixed content idea. My point is that it doesn't fix anything at all. Like filling 8/10 holes in a bucket of water. It's still going to leak out.
      - A1kmm 16y ago
        It is the webapp developer who ultimately decides whether or not there is mixed content, not the browser. If you don't mix content in your webapp, an attacker who controls the network shouldn't be able to change your content (not even to inject references to new untrusted HTTPS or plain HTTP servers), or that of trusted service providers. The browser needs to implement SSL securely, but even users with a browser with no mixed-content warning benefit from there being no mixed-content. The mixed content warning helps to warn the developer of the site of the problem, and let users of browsers that support it know that they are not fully protected.
  - zmmmmm 16y ago
    The problem is that you asserted it is "just as easy". 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.
    - kneath 16y ago
      Okay, here's another "just as easy" scenario: 1. You include http://google.com/trusted.js http://google.com/trusted.js on a https page 2. Someone goes to a cafe, opens up your website with Safari while someone is performing a MiTM attack on that file. 3. No warnings, your user is compromised.
      - zmmmmm 16y ago
        Any browser which doesn't warn about that in some way is essentially broken. (Yes, I see you cited Safari as one, but it must the the only one as far as I know - it does remove the padlock, but that seems pretty inadequate ...) EDIT: I do take your point in that I think IE is the only browser that actually blocks the content. The others warn about it but still load it, by which time, of course, the damage is done.
        othermaciej 16y ago
        Our theory is that an SSL site including non-SSL content is no better or worse, in terms of security, than a completely non-SSL site. What is the purpose of warning more prominently in the scenario described, than in the scenario where the user goes to a non-SSL site in the first page, or is redirected from an SSL login form to a non-SSL page?
      - tlrobinson 16y ago
        Yeah, then don't do that, that's the point. Whether you include mixed content in your site is up to you, the developer.
        16y ago
  - tlrobinson 16y ago
    Saying you can hack an analytics company's servers is cheating. I can just say I can hack GitHub's servers. Or obtain a root SSL cert. Or crack SSL. If you don't trust a company and their competency at security you probably shouldn't be using their service for anything sensitive. You can't assume that your users aren't on hostile networks vulnerable to MITM attacks, etc.
- mfukar 16y ago
  Right. Users never do that!
- jerf 16y ago
  Ask tptacek how hard it is to SSL man-in-the-middle attacks in the wild. Hint: People sell out-of-the-box solutions to the problem. It's trivial to get certs that browsers won't choke on. You have to more than check for the cert not being "invalid", you have to actually examine it carefully, knowing which cert sellers are trustworthy and which are not. Your SSL lock icon is useless.

by kneath 16y ago

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.
  - kneath 16y ago
    Unless they're using Safari which doesn't have a mixed content idea. My point is that it doesn't fix anything at all. Like filling 8/10 holes in a bucket of water. It's still going to leak out.
    - A1kmm 16y ago
      It is the webapp developer who ultimately decides whether or not there is mixed content, not the browser. If you don't mix content in your webapp, an attacker who controls the network shouldn't be able to change your content (not even to inject references to new untrusted HTTPS or plain HTTP servers), or that of trusted service providers. The browser needs to implement SSL securely, but even users with a browser with no mixed-content warning benefit from there being no mixed-content. The mixed content warning helps to warn the developer of the site of the problem, and let users of browsers that support it know that they are not fully protected.
- zmmmmm 16y ago
  The problem is that you asserted it is "just as easy". 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.
  - kneath 16y ago
    Okay, here's another "just as easy" scenario: 1. You include http://google.com/trusted.js http://google.com/trusted.js on a https page 2. Someone goes to a cafe, opens up your website with Safari while someone is performing a MiTM attack on that file. 3. No warnings, your user is compromised.
    - zmmmmm 16y ago
      Any browser which doesn't warn about that in some way is essentially broken. (Yes, I see you cited Safari as one, but it must the the only one as far as I know - it does remove the padlock, but that seems pretty inadequate ...) EDIT: I do take your point in that I think IE is the only browser that actually blocks the content. The others warn about it but still load it, by which time, of course, the damage is done.
      - othermaciej 16y ago
        Our theory is that an SSL site including non-SSL content is no better or worse, in terms of security, than a completely non-SSL site. What is the purpose of warning more prominently in the scenario described, than in the scenario where the user goes to a non-SSL site in the first page, or is redirected from an SSL login form to a non-SSL page?
    - tlrobinson 16y ago
      Yeah, then don't do that, that's the point. Whether you include mixed content in your site is up to you, the developer.
      - 16y ago
- tlrobinson 16y ago
  Saying you can hack an analytics company's servers is cheating. I can just say I can hack GitHub's servers. Or obtain a root SSL cert. Or crack SSL. If you don't trust a company and their competency at security you probably shouldn't be using their service for anything sensitive. You can't assume that your users aren't on hostile networks vulnerable to MITM attacks, etc.
mfukar 16y ago
Right. Users never do that!
jerf 16y ago
Ask tptacek how hard it is to SSL man-in-the-middle attacks in the wild. Hint: People sell out-of-the-box solutions to the problem. It's trivial to get certs that browsers won't choke on. You have to more than check for the cert not being "invalid", you have to actually examine it carefully, knowing which cert sellers are trustworthy and which are not. Your SSL lock icon is useless.