Hi Mikko,
Thanks for your comments! Chrome, IE, and Firefox all have a Mixed
Content Blocker. Chrome's implementation is a little less secure since
it does not block mixed iframes and mixed xhr. However, they are working
on improving their Mixed Content Blocker. Chrome 30 (currently Chrome
Canary) blocks mixed iframes and blocking mixed xhr is on the horizon
(if they haven't done it already).
You bring up a good point about sandboxed frames. The reason we block
frames is described in some detail here:
https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/#Mixed_Content_Frames.
If we were to reduce the risk that mixed frames pose by sandboxing them,
then perhaps we could downgrade them to mixed passive content and not
block them by default. I filed a bug for this and welcome feedback and
suggestions: https://bugzilla.mozilla.org/show_bug.cgi?id=903211. This
would provide a mechanism for developers to include third party mixed
content without requiring a proxy to covert the content to HTTPS.
However, the majority of websites are using regular iframes and not
sandboxed iframes. We should consider this when prioritizing this bug.
Some statistics would also be helpful.
On a side note, Ian mentioned a "neutral" mode for SSL, and I'm unclear
on what that is referring to. Some context would be helpful.
Thanks!
~Tanvi
On 8/12/13 5:32 AM, Mikko Rantalainen wrote:
On Monday, 12 August 2013 11:27:59 UTC+3, ianG wrote:
The only 'solution' is really to put everything into the secure side.
Unfortunately, I cannot control everything. I'm authoring a kind of CMS system
for educational use and I need to support user authored content. The whole
system uses only HTTPS connections for everything and the only thing that I
need is ability to say
<iframe isolation="sandbox" src="url-encoded-user-input">
where the "isolation" says that I want to keep this stuff in a sandbox and,
yes, I truly want to embed untrusted content in this box but I never want it to interact
with the main document in the any way. (Imagine a iframe pointing to youtube.com where
youtube.com would not support HTTPS connections...)
As far as I can tell, there's no way to escape that iframe even without the missing
"isolation" parameter as long as the sandboxed content comes from different
domain. As a result, that 3rd party HTTP content cannot mess with the secure site.
Unfortunately, that does not fit the "Passive Mixed Content" description of Firefox. I
understand being cautious with <script src="http://...";> but iframes
are totally different, unless I've misunderstood something seriously
incorrectly.
Note that the problem is that the content to be embedded within an iframe is
hosted by 3rd party that is not ready to jump to using HTTPS. Because of this,
my service would need to reduce the security to allow everything to work! And
this is supposed to improve end user security how?
Perhaps we need support for <iframe trustmeiknowwhatido=1 src="http://...";>
when using HTTPS connections?
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
