3 ms·
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 ca
by 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 agoAny 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 agoOur 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 agoYeah, then don't do that, that's the point. Whether you include mixed content in your site is up to you, the developer.
- kneath 16y agoThe entire concept of the SSL icon is so that a user can trust a third party (web developer) that they don't know. If it's up to you (the web developer) — it's all up in the air again. And the icon/warnings are pointless. Which is where I've been trying to go with this…
- JoachimSchipper 16y agoEh? SSL provides security against eavesdroppers, network manipulation, etc. - it doesn't help against a malicious site that you actually intended to communicate with.