Chrome fails CONNECT through HTTPS squid to unsecure upstream Jupyter

[ber...@gmail.com]

The setup:

Chrome <------- HTTPS w/ SPNEGO -----------> squid <----------- TCP listener w/o TLS / HTTP --------------> Jupyter

GET requests to establish the initial Jupyter client authenticate with SPNEGO and return successfully. It's happy to browse through directory structure and perform actions unrelated to a kernel. Once I attempt to connect to a kernel, Chrome issues a CONNECT (squid doesn't do websockets). Squid responds with a 407 but Chrome doesn't send a follow up to authenticate the CONNECT request. The in-browser Jupyter client reports it could not connect to the kernel.

Now, if I turn HTTPS on for the Jupyter listener, everything works as expected. When I load a kernel, Chrome issues a CONNECT, squid sends a 407, Chrome auths and the CONNECT goes through.

Why am I seeing different 407 behaviors for secure and unsecure upstreams?

For the sake of brevity and discussion, I can't turn on HTTPS for Jupyter.

[Ryan Hamilton]

Can you collect a NetLog?

https://dev.chromium.org/for-testers/providing-network-details

--
--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss

[Bill Bernsen]

It took me a minute to get around to collecting and sending out logs. They're attached. What I expect to see (and what happens when my upstream is HTTPS), is that in the proxy connection (e.g. 1510691) would follow up the proxy's 407 with a request containing an "Authorize: Negotiate..." header. In the logs, it looks like it simply tears down the TLS connection, forgets it was asked to auth, and tries again. This is consistent across log entries 1510658, 1510686, 1510691, and 1510709. Thank you for the help.

Cheers,

Bill

[Ryan Hamilton]

Thanks for the log! If I'm understanding correctly, it looks like the URL_REQUEST for id 1510658 is 1510650, which is for a ws:// URL. Is that right? I'm not entirely sure how ws connect tunnels interact with HTTP proxy auth. Can you file a new bug on crbug.com and let me know the ID. I'll make sure it ends up in front of the right eyes.

On Tue, Feb 12, 2019 at 12:25 AM <ber...@gmail.com> wrote:

--

[Bill Bernsen]

The initial URL_REQUEST for ws:// (e.g. 1510650) should fail - squid doesn't support websockets. It should then fall back to issuing a CONNECT request (e.g. 1510658) to squid. Squid sees this, sends back a 407, but the browser never attempts to reissue the request with credentials.

Bug report: 938977