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

Issue metadata

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

Sign in to add a comment

Issue 395614: webrtc TURN connection does not support NTLM Authentication

Reported by, 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
TURN server:

Authentication method used by the http proxy is NTLM

The TURN server used in this test is

related with  issue 394071 
62.5 KB Download

Comment 1 by, Jul 21 2014

Status: Assigned
Looks like the issue with WebSockets was fixed, but proxied TURN isn't working with NTLM. Jiayang, can you take a look?

Comment 2 by, Jul 21 2014

Labels: Cr-Blink-WebRTC

Comment 4 by, Jul 21 2014

Status: Unconfirmed

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, Jul 21 2014


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.
257 KB Download

Comment 6 by, Jul 21 2014

Could you share your squid configuration?

Comment 7 by, Jul 21 2014

Adding networking experts to help answer why the socket from net::InitSocketHandleForRawConnect does not handle the authentication response.

Comment 8 by, Jul 22 2014

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, Jul 22 2014

squid configuration attached.
2.9 KB Download

Comment 10 by, Jul 22 2014

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.

Comment 11 by, Jul 22 2014

#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, Jul 22 2014

Where does WebSocket get the credential?

Comment 13 by, Jul 22 2014

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, 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, Jul 22 2014


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

Comment 16 by, Jul 22 2014

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, Jul 28 2014

Hi All, I read the codereview, did we reach any conclusion about this? Are we going to change it or not?

Comment 19 by, Aug 15 2014

Any chance of an update on the status of this?

Comment 20 by, 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:!topic/net-dev/Rj7Mu160lT4

Please chime in if this is an important scenario for you and that will help us prioritize.

Comment 21 by, Aug 18 2014

This is an important scenario for WebRTC access from managed enterprise networks.

Comment 22 by, Aug 28 2014

Project Member
The following revision refers to this bug:

commit 260631aa62e2096045adb0e3780ef562ef12bb4f
Author: jiayl <>
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:

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


Comment 23 by, Sep 4 2014

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.

Comment 24 by, Sep 4 2014

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?


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

Comment 25 by, Sep 5 2014

Labels: -Merge-Requested Merge-Approved

Comment 26 by, Sep 6 2014

Project Member
Labels: -Merge-Approved merge-merged-2125
The following revision refers to this bug:

commit ce1ffabccb010c611768f1977f21ce707b5944e3
Author: Jiayang Liu <>
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:

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

Review URL:

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


Comment 27 by, Sep 6 2014

Status: Fixed

Comment 28 by, Sep 17 2014

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

Comment 29 by, Sep 17 2014

Thanks so much.

Sign in to add a comment