Closed Bug 1702417 Opened 10 months ago Closed 4 months ago

Connections to TCP/TLS/TURN server for WebRTC ICE do not use configured proxy

Categories

(Core :: WebRTC: Networking, defect, P2)

Firefox 87
defect

Tracking

()

RESOLVED FIXED
94 Branch
Tracking Status
firefox94 --- fixed

People

(Reporter: gabriel, Assigned: bwc, NeedInfo)

References

Details

Attachments

(11 files, 1 obsolete file)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0

Steps to reproduce:

about:config -> media.peerconnection.ice.relay_only = true

Since version 0.86 firefox cannot connect to the TURN server (turn:<turn-server>:443?transport=tcp) if proxy server is configured, and does not return a relay ICE candidate. With no proxy configured, the relay works.

Actual results:

Since version 0.86 firefox cannot connect to the TURN server (turn:<turn-server>:443?transport=tcp) if proxy server is configured, and does not return a relay ICE candidate. With no proxy configured, the relay works. See attachments: aboutWebrtc-relay-without-proxy.firefox-0.87.html, aboutWebrtc-relay-with-proxy.firefox-0.87.html

Expected results:

Firefox should connect to the TURN server via the configured proxy server, and return a relay ICE candidate. See attachment aboutWebrtc-relay-with-proxy-expected.firefox-0.85.html

Attachment #9213009 - Attachment is obsolete: true

Does it work if the TURN server is configured as an IP address instead of a domain name?

Flags: needinfo?(gabriel)

No, it makes no difference.

Flags: needinfo?(gabriel)

Oh, this is TURNS, not TURN. Maybe you're encountering bug 1702323? Is this busted for plain TURN? Does a binary from one of the try pushes in bug 1702323 fix the problem for you?

Flags: needinfo?(gabriel)

(In reply to Byron Campen [:bwc] from comment #6)

Does a binary from one of the try pushes in bug 1702323 fix the problem for you?

With the fix TURNS works :), but TURN unfortunately still does not work with a configured proxy.

Flags: needinfo?(gabriel)

(In reply to gabriel from comment #7)

(In reply to Byron Campen [:bwc] from comment #6)

Does a binary from one of the try pushes in bug 1702323 fix the problem for you?

With the fix TURNS works :), but TURN unfortunately still does not work with a configured proxy.

That's extremely interesting, because all that fix did was avoid stomping a tls bit in an address struct; I don't see how that would fix things only for TURNS. Can you attach an about:webrtc for this case?

(In reply to Byron Campen [:bwc] from comment #8)

That's extremely interesting, because all that fix did was avoid stomping a tls bit in an address struct; I don't see how that would fix things only for TURNS. Can you attach an about:webrtc for this case?

At least things looked good for TURNS in the Trickle ICE test https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/, but I do not fully understand the logs from about:webrtc.

Byron, can you help triage this?

Flags: needinfo?(docfaraday)

That's weird. Seeing an NS_ERROR_CONTENT_BLOCKED in the logging from comment 10...

Maybe we're hitting some sort of mixed content blocking? Is turn tcp working without a web proxy for you?

Flags: needinfo?(docfaraday) → needinfo?(gabriel)

Relay with TURN (137.248.X.Z) and no proxy works as it should be (see log of about:webrtc).

Flags: needinfo?(gabriel)
Flags: needinfo?(docfaraday)

This really does look like a mixed content blocking thing, but it only happens with web-proxy, so that means it is probably happening here:

https://searchfox.org/mozilla-central/rev/6cbe34b441f7c7c29cd1e5f0e19c7000142f1423/dom/media/webrtc/transport/ipc/WebrtcTCPSocket.cpp#386-403

Since the origin was loaded with https, necko is refusing to open an http proxy channel, which makes sense in the general case, but not for webrtc probably.

baku, what's the proper way of tweaking the LoadInfoArgs to avoid mixed content blocking for this case? blockAllMixedContent?

Flags: needinfo?(docfaraday) → needinfo?(amarchesini)

Hi, we have the exact same problem here. NS_ERROR_CONTENT_BLOCKED
It works with some clients, with other clients it does not work and we see the error in the webrtc log.
I have absolutly no clue what the difference between working and non working clients could be.

Without a proxy it works from the same client computers.

I am having this issue too. We are seeing it on TURN without TLS.

Severity: -- → S2
Priority: -- → P2
Assignee: nobody → docfaraday

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?

^

Flags: needinfo?(amarchesini) → needinfo?(fbraun)

Presently, there is no way to test this in an automated fashion, since mochitest runs all of its traffic through a fake web-proxy. I have tested by hand, reproduced the problem, and verified the fix works.

(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?

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..

Flags: needinfo?(fbraun) → needinfo?(dd.mozilla)

(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?

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.

Byron is right (comment 36). There is no exception for normal http request and WebRTC is something different.

Flags: needinfo?(dd.mozilla)
Attachment #9238923 - Attachment description: Bug 1702417: Add a content policy for webrtc connections that does not subject them to mixed content blocking. r?baku → Bug 1702417: Add a content policy for webrtc connections over http proxies, so they are not subject to mixed content blocking. r?baku

We add the new content policy here, but leave the behavior as TYPE_OTHER, so
we can verify that the new test fails before the fix is applied.

Depends on D124200

Attachment #9238923 - Attachment description: Bug 1702417: Add a content policy for webrtc connections over http proxies, so they are not subject to mixed content blocking. r?baku → Bug 1702417: Do not subject webrtc media connections to mixed content blocking. r?freddyb
Duplicate of this bug: 1730366

Try looks good.

Pushed by bcampen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/014573f5ac30
Add a block_tls option to the NAT simulator. r=mjf
https://hg.mozilla.org/integration/autoland/rev/b10e7a7b8fa4
Teach the NAT simulator to support web proxy config. r=mjf
https://hg.mozilla.org/integration/autoland/rev/7a62ebf30d7f
Add some logging to WebrtcTCPSocket to make it possible to tell whether web-proxy was used. r=mjf
https://hg.mozilla.org/integration/autoland/rev/3ae3d328c7ed
Test case for bug. r=freddyb,mixedpuppy,necko-reviewers
https://hg.mozilla.org/integration/autoland/rev/959b02029bf6
Do not subject webrtc media connections to mixed content blocking. r=mixedpuppy,freddyb

Hi!

Our tests have shown this fix is working on FF94 up.

As companies (including us) are usualy on latest Firefox ESR, is it planned to backport this fix to 91esr?

Best regards,

Thomas

We did not have any plans to uplift to ESR, but maybe this could be a candidate if there's enough interest. I'm going to ask around.

Flags: needinfo?(tmiv74)
Flags: needinfo?(post)
Flags: needinfo?(gabriel)

Hi,

Same symptoms here with FF ESR 91.4 with proxified TURN relay (only [non-proxied] ICE candidates in about:webrtc).

Confirm problem solved using FF 95, showing "udp/(relay-tcp) [proxied]" in about:webrtc and bbb working great.

Our public administration is using ESR version of FF of course, so a backport in 91-esr branch would be very useful.

Cheers.

Vincent

You need to log in before you can comment on or make changes to this bug.