Bugzilla

(In reply to Frederik Braun [:freddy] from comment #35)
> (In reply to Byron Campen [:bwc] from comment #22)
> > Setting blockAllMixedContent does not seem to help. I can "fix" this by setting the triggering principal to the system principal, but that may be too blunt of an instrument. Maybe we need a new content policy for webrtc connections via an http proxy, and a new case in [here](https://searchfox.org/mozilla-central/rev/ad2ffab089e4e0c0fe99a1a046ab2b1c45546bdb/dom/security/nsMixedContentBlocker.cpp#507)?
> 
> Sorry about the review comment from about 5 minutes ago. That was about this approach, but think this approach isn't exactly correct.
> 
> I wonder what we do for HTTP proxies that sit beyond a normal HTTP request? How do we exempt those from content security checks?
> I haven't dealt with that code in particular, but maybe there is some sort of ProxyChannel you want to open? I hope a necko peer can help us here..

I don't think we do exempt them, and I don't think we should be. Just because something is loaded via a proxy shouldn't exempt it from the same checking that would happen without a proxy. In the webrtc case, mixed content checking simply makes no sense in any scenario, since webrtc media is peer-to-peer, and always encrypted anyway.

(In reply to Frederik Braun [:freddy] from comment #35)
> (In reply to Byron Campen [:bwc] from comment #22)
> > Setting blockAllMixedContent does not seem to help. I can "fix" this by setting the triggering principal to the system principal, but that may be too blunt of an instrument. Maybe we need a new content policy for webrtc connections via an http proxy, and a new case in [here](https://searchfox.org/mozilla-central/rev/ad2ffab089e4e0c0fe99a1a046ab2b1c45546bdb/dom/security/nsMixedContentBlocker.cpp#507)?
> 
> Sorry about the review comment from about 5 minutes ago. That was about this approach, but think this approach isn't exactly correct.
> 
> I wonder what we do for HTTP proxies that sit beyond a normal HTTP request? How do we exempt those from content security checks?
> I haven't dealt with that code in particular, but maybe there is some sort of ProxyChannel you want to open? I hope a necko peer can help us here..

I don't think we do exempt them, and I don't think we should be. Just because something is loaded via a proxy shouldn't exempt it from the same checking that would happen without a proxy. In the webrtc case, mixed content checking simply makes no sense in any scenario, since webrtc media is peer-to-peer, and always encrypted anyway. It isn't so much the _proxied_ bit that is important, it is the _webrtc_ bit; the proxied bit only matters because that's what causes the content security code to be in the path. Without a web-proxy, we just hit low-level socket API that does not have any content security stuff.