New issue
Advanced search Search tips

Issue 684730 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: May 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Remove deprecated cipher fallback

Project Member Reported by davidben@chromium.org, Jan 24 2017

Issue description

Now that DHE is gone, we don't need the deprecated cipher fallback for now. (We may need it again later, but while it's not doing anything, we should take it out.) Filing a bug for this so I don't forget; I'll need to split that half of the CL out of https://codereview.chromium.org/2653773003/ and do it as a follow-up since some proxy auth test is relying on it.

(mmenke@ and I understand what's going on with the test, but need to double-check with asanka@ about HTTP auth to make sure our fix is correct.)
 
Issue 675828 has been merged into this issue.
Status: Started (was: Assigned)
This is one proposal for fixing the HTTP auth dependency.
https://codereview.chromium.org/2688173002/
Project Member

Comment 3 by bugdroid1@chromium.org, Apr 17 2017

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

commit 8c7089a4184074fb5edcc9865906147e185f0514
Author: davidben <davidben@chromium.org>
Date: Mon Apr 17 20:38:37 2017

Don't rely on SSL cipher fallback in proxy auth.

When doing HTTP proxy auth, we may need to continue or retry auth on a
fresh connection. This may happen if the server did not allow keep-alive
or if the server timed out while we were prompting the user.

In response to this, we may choose to continue the existing
HttpAuthHandler state on a new connection (which would require the
server not bind auth state to the connection) or to restart it (if the
server did do so).

The existing logic in HttpProxyClientSocketWrapper distinguished these
cases with the ERR_UNABLE_TO_REUSE_CONNECTION_FOR_PROXY_AUTH error code;
if we had not send anything out of the HttpAuthController yet, we assume
that it's okay to continue without a reset. (We can't simply reset it
every time because a server which does not support connection reuse at
all would never make progress.)

If we had extracted a token from the HttpAuthController and hit an error
reading the response, HttpProxyClientSocketWrapper would forward the
error up to be retried at a higher level. However, there was no higher
level logic to retry it. The usual socket reuse race condition retry
acts on a different set of signals. Instead, we were relying on the SSL
cipher fallback (which triggers on a similar set of errors) to restart
everything from the top.

Instead, if we see an error code indicative of such a race, retry at the
HttpProxyClientSocketWrapper level, after telling the HttpAuthController
to drop all state from the current HttpAuthHandler. This unblocks
removing the now otherwise unused SSL cipher fallback.

BUG= 684730 

Review-Url: https://codereview.chromium.org/2688173002
Cr-Commit-Position: refs/heads/master@{#465009}

[modify] https://crrev.com/8c7089a4184074fb5edcc9865906147e185f0514/net/http/http_auth_controller.cc
[modify] https://crrev.com/8c7089a4184074fb5edcc9865906147e185f0514/net/http/http_auth_controller.h
[modify] https://crrev.com/8c7089a4184074fb5edcc9865906147e185f0514/net/http/http_network_transaction_unittest.cc
[modify] https://crrev.com/8c7089a4184074fb5edcc9865906147e185f0514/net/http/http_proxy_client_socket.cc
[modify] https://crrev.com/8c7089a4184074fb5edcc9865906147e185f0514/net/http/http_proxy_client_socket_wrapper.cc
[modify] https://crrev.com/8c7089a4184074fb5edcc9865906147e185f0514/net/http/http_proxy_client_socket_wrapper.h

Project Member

Comment 4 by bugdroid1@chromium.org, May 5 2017

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

commit a4449725c3c1d07ecd8008d5d03227c4588b85dc
Author: davidben <davidben@chromium.org>
Date: Fri May 05 23:30:53 2017

Fix QuicNetworkTransactionTest.RetryMisdirectedRequest

This test was depending on the SSL deprecated cipher fallback (which is
a quirk to probe server cipher preferences and not something QUIC may
depend on) to clear away the ERR_CONNECTION_CLOSED when it shouldn't
have been surfacing one to begin with.

Fortunately, the actual logic isn't relying on this. The test just needs
fixing. Rather than scheduling three connections, schedule two. The main
job hangs until after all the QUIC machinery is done, then we unblock
the main job and let that complete.

BUG= 546991 , 684730 

Review-Url: https://codereview.chromium.org/2856073003
Cr-Commit-Position: refs/heads/master@{#469799}

[modify] https://crrev.com/a4449725c3c1d07ecd8008d5d03227c4588b85dc/net/quic/chromium/quic_network_transaction_unittest.cc

Project Member

Comment 5 by bugdroid1@chromium.org, May 10 2017

Status: Fixed (was: Started)

Sign in to add a comment