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

Status: RESOLVED FIXED

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

Description

[gabriel]

Attachment: aboutWebrtc-relay-with-proxy.firefox-0.87.html

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

Comment 1

[gabriel]

Attachment: aboutWebrtc-relay-with-proxy.firefox-0.87.html

Comment 2

[gabriel]

Attachment: aboutWebrtc-relay-with-proxy-expected.firefox-0.85.html

Comment 3

[gabriel]

Attachment: aboutWebrtc-relay-without-proxy.firefox-0.87.html

Comment 4

[Byron Campen [:bwc]]

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

Comment 5

[gabriel]

No, it makes no difference.

Comment 6

[Byron Campen [:bwc]]

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?

Comment 7

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

Comment 8

[Byron Campen [:bwc]]

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

Comment 9

[gabriel]

Attachment: aboutWebrtc-turns-proxy-1702323.html

Comment 10

[gabriel]

Attachment: aboutWebrtc-turn-proxy-1702323.html

Comment 11

[gabriel]

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

Comment 12

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Byron, can you help triage this?

Comment 13

[Byron Campen [:bwc]]

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?

Comment 14

[gabriel]

Attachment: aboutWebrtc-turn-no-proxy-1702323.html

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

Comment 15

[Byron Campen [:bwc]]

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?

Comment 16

[user1234]

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.

Comment 17

[tmiv74]

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

Comment 18

[Byron Campen [:bwc]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=24fd6e089ff1968bc5db0733b1048f1f00eb47d7
https://treeherder.mozilla.org/#/jobs?repo=try&revision=a8e065216ea669890b689cb9884c926439a3cc2d

Comment 19

[Byron Campen [:bwc]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=dfea14ca058d677161ff0183c3fc9c7e6871e63a

Comment 20

[Byron Campen [:bwc]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=57581d8cc836bf95d5321025425e627ec4599411

Comment 21

[Byron Campen [:bwc]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=8d411a3dc71ae8a0cdaab424abfbeb6efa29f8de

Comment 22

[Byron Campen [:bwc]]

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?

Comment 23

[Byron Campen [:bwc]]

^

Comment 24

[Byron Campen [:bwc]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=14bd0da138f073117388f379bc030fc13c8f9222

Comment 25

[Byron Campen [:bwc]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=e1dade6b513546a06d3216764ab033f15e0c83a7

Comment 26

[Byron Campen [:bwc]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=61c211bfbb325433e108725954b445bcbe819f9a

Comment 27

[Byron Campen [:bwc]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=a1b30065208a9736d0d6da71182ffd76bf680e57

Comment 28

[Byron Campen [:bwc]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=0537c62c7eadf525d7817feb3e22a515087ad392

Comment 29

[Byron Campen [:bwc]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=134acabae5a92573d9ad9de89a915af11b49ef0a
https://treeherder.mozilla.org/#/jobs?repo=try&revision=998380e14875472370bdf13a6845dbd491051fcc
https://treeherder.mozilla.org/#/jobs?repo=try&revision=35ea5364104336a5d48c8cf0abcd69b97d9513f8

Comment 30

[Byron Campen [:bwc]]

Attachment: Bug 1702417: Add a block_tls option to the NAT simulator. r?mjf

Comment 31

[Byron Campen [:bwc]]

Attachment: Bug 1702417: Teach the NAT simulator to support web proxy config. r?mjf

Depends on D124198

Comment 32

[Byron Campen [:bwc]]

Attachment: Bug 1702417: Add some logging to WebrtcTCPSocket to make it possible to tell whether web-proxy was used. r?mjf

Depends on D124199

Comment 33

[Byron Campen [:bwc]]

Attachment: Bug 1702417: Do not subject webrtc media connections to mixed content blocking. r?freddyb

Depends on D124200

Comment 34

[Byron Campen [:bwc]]

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.

Comment 35

[Frederik Braun [:freddy] (OOO - Back April 8th)]

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

Comment 36

[Byron Campen [:bwc]]

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

Comment 37

[Byron Campen [:bwc]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=3ea131851d2d1bda823099569501717f3c5e2e50

Comment 38

[Byron Campen [:bwc]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=ae5b56ec92c7db8608824805aad7284ecea59c9c

Comment 39

[Dragana Damjanovic [:dragana]]

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

Comment 40

[Byron Campen [:bwc]]

Attachment: Bug 1702417: Test case for bug. r?freddyb,mixedpuppy

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

Comment 41

[Byron Campen [:bwc]]

xpcshell: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b2178e0e5ef61ac945540ef2fa719060f1a2f616
mochitest: https://treeherder.mozilla.org/#/jobs?repo=try&revision=c1fedd20d27fda12ef59806b087d114fc96ff672
wpt: https://treeherder.mozilla.org/#/jobs?repo=try&revision=417e01b736ea808f6aea8708c6441a2e5028148c

Comment 43

[Byron Campen [:bwc]]

Try looks good.

Comment 44

[Pulsebot]

Pushed by [e-mail]:
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

Comment 45

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/014573f5ac30
https://hg.mozilla.org/mozilla-central/rev/b10e7a7b8fa4
https://hg.mozilla.org/mozilla-central/rev/7a62ebf30d7f
https://hg.mozilla.org/mozilla-central/rev/3ae3d328c7ed
https://hg.mozilla.org/mozilla-central/rev/959b02029bf6

Comment 46

[thomas.krueger]

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

Comment 47

[Byron Campen [:bwc]]

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.

Comment 48

[vincent]

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