Does webrtc support socks5 UDP proxies?

[Dennis]

Will webrtc ICE connection/STUN/UDP media work through a socks5 proxy server?   I completely understand TURN servers and their solutions etc, and am just wondering whether or not webrtc would work through a vanilla SOCKS5 udp proxy.

AFAIU socks5 is usually tcp etc etc, not many (if any at all) support UDP, but i can see in the SOCKS5 protocol a request to associate UDP ports is there.  So assuming there is socks5 proxies out there that support UDP proxying, I am wondering if chrome/webrtc provides any capability to use SOCKS5 proxies to establish outbound connections to a public facing media relay.   I'm not sure how ports and ice candidate gathering etc would work in this situation if supported, especially if the remote candidates are different ip's altogether thus requiring multiple bindings...

I'm assuming its not supported, just figured I'd confirm that here.

[Taylor Brandstetter]

Actually, I just recently removed some code for dealing with SOCKS servers (TCP-only): https://codereview.webrtc.org/2731673002/

But as far as I know, there's never been a way to access this functionality through Chrome. 

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/9d3f3993-9c3d-4a00-bb28-7ae908b3a3e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Haseeb Abdul Qadir]

> Actually, I just recently removed some code for dealing with SOCKS servers (TCP-only): https://codereview.webrtc.org/2731673002/

We have a native app that uses this code on Windows and Macs extensively. There are quite a few Enterprise environments where communication is only allowed via HTTPS/SOCKS proxies. Chrome might not need this but native apps (like ours) find this useful. Would it be possible to revert this change? 

 

On Monday, March 13, 2017 at 5:18:16 PM UTC-4, Taylor Brandstetter wrote:

Actually, I just recently removed some code for dealing with SOCKS servers (TCP-only): https://codereview.webrtc.org/2731673002/

But as far as I know, there's never been a way to access this functionality through Chrome. 

On Mon, Mar 13, 2017 at 12:14 PM, Dennis <ddo...@gmail.com> wrote:

Will webrtc ICE connection/STUN/UDP media work through a socks5 proxy server?   I completely understand TURN servers and their solutions etc, and am just wondering whether or not webrtc would work through a vanilla SOCKS5 udp proxy.

AFAIU socks5 is usually tcp etc etc, not many (if any at all) support UDP, but i can see in the SOCKS5 protocol a request to associate UDP ports is there.  So assuming there is socks5 proxies out there that support UDP proxying, I am wondering if chrome/webrtc provides any capability to use SOCKS5 proxies to establish outbound connections to a public facing media relay.   I'm not sure how ports and ice candidate gathering etc would work in this situation if supported, especially if the remote candidates are different ip's altogether thus requiring multiple bindings...

I'm assuming its not supported, just figured I'd confirm that here.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

[Taylor Brandstetter]

I didn't know this code was being used by anyone; in that case I can revert the CL for the time being, but we'd like to avoid maintaining this code forever, since it's not used by standard WebRTC, and it has almost no test coverage.

A few questions for you:

• Are there situations where an HTTPS/SOCKS proxy works, but a TCP TURN server on port 443 doesn't?
• How are you accessing this functionality? Do you create your own "PortAllocator" object and call "set_proxy" on it, causing outgoing TCP connections to go through the proxy?
• What remote endpoint is the WebRTC endpoint connecting to? Another WebRTC endpoint? If so, how does this work, since our SOCKS code only handles outgoing connections? Do you use the HTTPS/SOCKS proxy in combination with a TURN server?

I think the best path forward may be for you to fork our proxy code, and provide your own "PacketSocketFactory" implementation that uses it. This is effectively what Chrome does, when Chrome is configured with a proxy.

On Tue, Mar 14, 2017 at 10:30 AM, Haseeb Abdul Qadir <has...@jumpdesktop.com> wrote:

> Actually, I just recently removed some code for dealing with SOCKS servers (TCP-only): https://codereview.webrtc.org/2731673002/

We have a native app that uses this code on Windows and Macs extensively. There are quite a few Enterprise environments where communication is only allowed via HTTPS/SOCKS proxies. Chrome might not need this but native apps (like ours) find this useful. Would it be possible to revert this change? 

 

On Monday, March 13, 2017 at 5:18:16 PM UTC-4, Taylor Brandstetter wrote:

Actually, I just recently removed some code for dealing with SOCKS servers (TCP-only): https://codereview.webrtc.org/2731673002/

But as far as I know, there's never been a way to access this functionality through Chrome. 

On Mon, Mar 13, 2017 at 12:14 PM, Dennis <ddo...@gmail.com> wrote:

Will webrtc ICE connection/STUN/UDP media work through a socks5 proxy server?   I completely understand TURN servers and their solutions etc, and am just wondering whether or not webrtc would work through a vanilla SOCKS5 udp proxy.

AFAIU socks5 is usually tcp etc etc, not many (if any at all) support UDP, but i can see in the SOCKS5 protocol a request to associate UDP ports is there.  So assuming there is socks5 proxies out there that support UDP proxying, I am wondering if chrome/webrtc provides any capability to use SOCKS5 proxies to establish outbound connections to a public facing media relay.   I'm not sure how ports and ice candidate gathering etc would work in this situation if supported, especially if the remote candidates are different ip's altogether thus requiring multiple bindings...

I'm assuming its not supported, just figured I'd confirm that here.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/9d3f3993-9c3d-4a00-bb28-7ae908b3a3e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/7549f48a-d2b1-4f5f-8852-96f432434fe9%40googlegroups.com.

[Haseeb Abdul Qadir]

> that case I can revert the CL for the time being

Thank you very much - this is much appreciated.

• Are there situations where an HTTPS/SOCKS proxy works, but a TCP TURN server on port 443 doesn't

Yes, this happens on very locked down networks when all outside/WAN communication must go through a proxy server. In these cases TCP TURN can’t connect directly to the public TURN server on port 443 - it must go through the proxy. There are also other cases where you'd want to provide an alternative means of connecting to the WAN (i.e. when public servers are blocked). The use-case is ~ similar to Chrome’s, I guess.

• How are you accessing this functionality? Do you create your own "PortAllocator" object and call "set_proxy" on it, causing outgoing TCP connections to go through the proxy?

This is exactly how we’re doing it.

• What remote endpoint is the WebRTC endpoint connecting to? Another WebRTC endpoint? If so, how does this work, since our SOCKS code only handles outgoing connections? Do you use the HTTPS/SOCKS proxy in combination with a TURN server?

Correct: we’re using TURN severs in combination with HTTPS/SOCKS proxies. The other endpoint could have HTTP/SOCKS enabled as well. As you’ve mentioned, in these cases the connection flows through the TURN server.

I think the best path forward may be for you to fork our proxy code, and provide your own "PacketSocketFactory" implementation that uses it

Thanks for pointing us the right direction - we’ll look into this. Though, to be quite honest, I’m surprised that other consumers of the native API directly won’t have the same need.

You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/E3FX4bp363M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAK35n0YO1_hSEL%2BCHh1Jk7S4-5zoQ1ej220QxBM9kO9AiQ6K2A%40mail.gmail.com.

[Silvia Pfeiffer]

On 15 Mar. 2017 6:49 am, "'Taylor Brandstetter' via discuss-webrtc" <discuss...@googlegroups.com> wrote:

I didn't know this code was being used by anyone; in that case I can revert the CL for the time being, but we'd like to avoid maintaining this code forever, since it's not used by standard WebRTC, and it has almost no test coverage.

A few questions for you:

• Are there situations where an HTTPS/SOCKS proxy works, but a TCP TURN server on port 443 doesn't?
• How are you accessing this functionality? Do you create your own "PortAllocator" object and call "set_proxy" on it, causing outgoing TCP connections to go through the proxy?
• What remote endpoint is the WebRTC endpoint connecting to? Another WebRTC endpoint? If so, how does this work, since our SOCKS code only handles outgoing connections? Do you use the HTTPS/SOCKS proxy in combination with a TURN server?

I think the best path forward may be for you to fork our proxy code, and provide your own "PacketSocketFactory" implementation that uses it. This is effectively what Chrome does, when Chrome is configured with a proxy.

Is it even possible to get WebRTC to connect through a socks proxy using standard chrome? I don't think it works, which is a real pita in a corporate environment that is completely locked down. Rather than removing code that half supports it, could this be fixed to completely support it, including incoming connections? I'd like to avoid everyone having to create their own chrome clone for their service to get through a socks proxy.

Cheers,

Silvia.

[Dennis Dowhy]

this is exactly the situation we're running into, as many of our client's corporate environments have an extremely locked down policy forcing all traffic to go through SOCKS proxy servers, and this does not play with with standard chrome and we are debating spending time creating a custom home grown solution for it where we'd have to individually authenticate and send udp-associates per remote ice candidate and munge the sdp to replace them with the socks5 bindings.

On Wed, Mar 15, 2017 at 4:27 PM, Silvia Pfeiffer <silviap...@gmail.com> wrote:

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAHp8n2%3DKmiXzbNeG5p-q_Nu8BYsZSs57L8ki1%3DCG_Ex4iPJC3w%40mail.gmail.com.

[andreas....@xmreality.se]

I would just like to add, while we currently are not utilizing SOCKS proxy in our native app we will almost certainly soon need to due to deployment in very locked down corporate networks.  

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/7549f48a-d2b1-4f5f-8852-96f432434fe9%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Silvia Pfeiffer]

In theory, i think https://bugs.chromium.org/p/chromium/issues/detail?id=439560 should have fixed the issues, but it looks like there are still some bugs?

Best Regards,
Silvia.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/c102f305-de09-47a0-805d-31efa576f25c%40googlegroups.com.

[Dennis Dowhy]

Our app hasn't caught up to M56 yet, currently using M48/M49, but will that change described here https://bugs.chromium.org/p/chromium/issues/detail?id=439560 work for SOCKS5 UDP-associate proxies if the remote sdp offer provides 3 separate UDP ip:port ice candidates?

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAHp8n2%3DTy5YONH4v9s%3DiN2y8Ji07RMVfVkm5TCQ3RfWkvcsBjg%40mail.gmail.com.

[Paride]

Thank you very much for reverting the commit.
Please do not deprecate the support for SOCKS proxies, as others said it's really important in environments with a restrictive network policy.

[Taylor Brandstetter]

I believe an application can achieve the same thing by simply forking our SOCKS client code, and passing a subclass of PacketSocketFactory that uses it into the BasicPortAllocator constructor, as mentioned above. That's what I was planning on suggesting as an alternative. Do you see any potential issues with this?

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/9ec23b63-2de6-4c6d-9a09-029feaf80e6f%40googlegroups.com.