New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 395614 link

Starred by 15 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Sep 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

webrtc TURN connection does not support NTLM Authentication

Reported by imba...@gmail.com, Jul 21 2014

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Create a peerconnection and pass turn server address to it. The peerconnection is created behind a HTTP proxy, TURN server is deployed out of the proxy
2. TURN server offers TLS
3. HTTP server enables NTLM authentication

What is the expected behavior?
peerconnection connects to the TURN server to collect relay candidates. Since its behind a proxy, it creates a HTTP tunnel with the proxy first and sends the TURN messages via the tunnel. peerconnection should be able to pass the HTTP authentication in order to create the tunnel.

What went wrong?
When attempting to create the HTTP tunnel, the peerconnection does not respond to the proxy's authentication requests. Specifically for NTLM, the peerconnection does not respond to 407 response for the CONNECT request so the tunnel can not be established and the relay candidates are not collected.

Did this work before? No 

Chrome version: 36.0.1985.125  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version: Shockwave Flash 14.0 r0

See attached trace
Chrome: 10.231.150.51
Proxy: 10.231.150.30
TURN server: 10.231.52.133

Authentication method used by the http proxy is NTLM

The TURN server used in this test is https://code.google.com/p/rfc5766-turn-server/

related with  issue 394071 
 
turn.pcapng
62.5 KB Download
Cc: mallinath@chromium.org
Owner: jiayl@chromium.org
Status: Assigned
Looks like the issue with WebSockets was fixed, but proxied TURN isn't working with NTLM. Jiayang, can you take a look?
Labels: Cr-Blink-WebRTC

Comment 4 by jiayl@chromium.org, Jul 21 2014

Status: Unconfirmed
imbaoyu,

could you reproduce it on Chrome Canary? I cannot reproduce it, i.e. relay candidates allocated from TURN server outside the http proxy.

Comment 5 by imba...@gmail.com, Jul 21 2014

Jiayang,

Yes I did test it with Canary, result is the same. I attached new trace with Canary.
Notice HTTP CONNECT at No.350, 358, 359 and 360, they receive 407 response from proxy at No.370, 375, 380 and 385 but Chrome never tried to send the CONNECT again.

The proxy I used to get the trace is squid (latest build).

If its working in your environment can you attach the wireshark trace? We can then compare the two to see whats the difference.
turn_canary.pcapng
257 KB Download

Comment 6 by jiayl@chromium.org, Jul 21 2014

Could you share your squid configuration?

Comment 7 by jiayl@chromium.org, Jul 21 2014

Cc: willchan@chromium.org mmenke@chromium.org
Adding networking experts to help answer why the socket from net::InitSocketHandleForRawConnect does not handle the authentication response.
It's not the job of the transport stream socket to handle the authentication. It's the job of the HTTP transaction to handle HTTP responses like 407s.

Comment 9 by imba...@gmail.com, Jul 22 2014

squid configuration attached.
squid.conf
2.9 KB Download
Cc: asanka@chromium.org
Actually, I believe proxy sockets do handle authentication, but when they don't have credentials, it's up to the embedder to make sure they have credentials, and then tell them to try again, with auth information...  Or at least, that's my understanding.
#10: That's correct. The HttpProxyClientSocket owns a HttpAuthController for responding to proxy auth requests during tunnel establishment. The Connect() method handles the work of invoking the auth controller if the socket is establishing a tunnel. It's done this way since the socket's Connect() needs to complete *before* the HttpNetworkTransaction can start sending the request. As it is, for the non-tunnel case we only see the 407 *after* the request is sent. Thus HttpNetworkTransaction also keeps an HttpAuthController around to respond to those.

If the HttpProxyClientSocket's HttpAuthController fails to respond to a 407 (due to the absence of credentials), the Connect() returns an ERR_PROXY_AUTH_REQUESTED which bubbles up to the embedder so that that explicit credentials can be supplied (e.g. by prompting the user).

Comment 12 by jiayl@chromium.org, Jul 22 2014

Where does WebSocket get the credential?
https://code.google.com/p/chromium/issues/detail?id=47069#c33

You need to connect via normal HTTP once and share the HTTP auth
credentials with that. I don't believe WebSockets support prompting the
user for HTTP authentication, it must be done by the document.

Comment 14 by jiayl@chromium.org, Jul 22 2014

Status: Assigned
Is URLRequest the right class to use to make the HTTP request? 
I suppose I can pass the ProxyResolvingClientSocket's network_session_->http_auth_cache() to URLRequestContext to share the proxy credentials.

Comment 15 by jiayl@chromium.org, Jul 22 2014

willchan@,

I tried making an http request through HttpNetworkTransaction, but it does not trigger the user prompt either. Could you advise on how to "connect via normal HTTP once"?
There are too many possible reasons for why this could go wrong :) Want to upload a diff and link me on Rietveld? I can take a look at what you're doing.

Comment 18 by imba...@gmail.com, Jul 28 2014

Hi All, I read the codereview, did we reach any conclusion about this? Are we going to change it or not? 
Any chance of an update on the status of this?

Comment 20 by jiayl@chromium.org, Aug 15 2014

We are working with the Chrome network team to find the best way to solve it, but no concrete plan yet. You can follow this thread for updates: https://groups.google.com/a/chromium.org/forum/#!topic/net-dev/Rj7Mu160lT4

Please chime in if this is an important scenario for you and that will help us prioritize.
This is an important scenario for WebRTC access from managed enterprise networks.
Project Member

Comment 22 by bugdroid1@chromium.org, Aug 28 2014

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/260631aa62e2096045adb0e3780ef562ef12bb4f

commit 260631aa62e2096045adb0e3780ef562ef12bb4f
Author: jiayl <jiayl@chromium.org>
Date: Thu Aug 28 18:47:25 2014

Handles proxy authentication request in ProxyResolvingClientSocket.
This will make the WebRTC connection work under NTLM/Kerberos using the default credential without prompting the user.

BUG= 395614 

Review URL: https://codereview.chromium.org/414523005

Cr-Commit-Position: refs/heads/master@{#292428}

[modify] https://chromium.googlesource.com/chromium/src.git/+/260631aa62e2096045adb0e3780ef562ef12bb4f/jingle/glue/proxy_resolving_client_socket.cc

Labels: Merge-Requested M-38
Summary: webrtc TURN connection does not support NTLM Authentication (was: webrtc TURN connection does not support HTTP Authentication)
The fix has been in Canary since last week and the customers verified that the fix worked in their corp network.

So requesting to merge to M38.
Labels: merge-questions-applied

Please note that all merge requests must have been on or rolled into trunk
for at least 24 hours to be considered for merging (to ensure full bot
coverage and give an opportunity for any necessary reverts to occur).

To help facilitate this request, if you could please answer the following:
--------------------------------------------------------------------------
1) Has this change been on trunk for at least 24 hours?

2) Has this change shipped to at least one canary release (where applicable)?

3) Has anyone verified that these changes resolve the issue and cause no new
   crashes (via chromecrash/) or regressions?

4) Why is this necessary for this milestone?

Thanks!

(this message is auto-generated each time the merge-request label is
applied; if you have previously answered these questions kindly disregard)

Labels: -Merge-Requested Merge-Approved
Project Member

Comment 26 by bugdroid1@chromium.org, Sep 6 2014

Labels: -Merge-Approved merge-merged-2125
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ce1ffabccb010c611768f1977f21ce707b5944e3

commit ce1ffabccb010c611768f1977f21ce707b5944e3
Author: Jiayang Liu <jiayl@chromium.org>
Date: Fri Sep 05 23:57:14 2014

Handles proxy authentication request in ProxyResolvingClientSocket. This will make the WebRTC connection work under NTLM/Kerberos using the default credential without prompting the user.

BUG= 395614 

Review URL: https://codereview.chromium.org/414523005

Cr-Commit-Position: refs/heads/master@{#292428}
(cherry picked from commit 260631aa62e2096045adb0e3780ef562ef12bb4f)

Review URL: https://codereview.chromium.org/543293002

Cr-Commit-Position: refs/branch-heads/2125@{#251}
Cr-Branched-From: b68026d94bda36dd106a3d91a098719f952a9477-refs/heads/master@{#290040}

[modify] https://chromium.googlesource.com/chromium/src.git/+/ce1ffabccb010c611768f1977f21ce707b5944e3/jingle/glue/proxy_resolving_client_socket.cc

Status: Fixed
Thanks for getting this fixed so quickly I know it was quite a difficult one.

Comment 29 by gmag...@gmail.com, Sep 17 2014

Thanks so much. 

Sign in to add a comment