Unit test for testing SSL client auth with both a proxy and an SSL endpoint

Unit test to demonstrate that you cannot (currently) use independent SSL client certificates with an HTTPS proxy connecting to an SSL server.

BUG=59292
TEST=HttpNetworkTransactionTest.HTTPSProxyAuthAndSSLClientAuth

[Ryan Sleevi, 2011-01-09 12:51:33]

Ryan,

  Here's a unit test that builds on both http://codereview.chromium.org/6120002/
and http://codereview.chromium.org/6017010/ (again, due to the test util
changes) that demonstrates the problem I mentioned via e-mail.

  Because HttpNetworkTransaction's ssl_config_ is re-used between the proxy
socket and the endpoint socket, it's not currently possible to provide different
client certificates between the two.

  As implemented, an SSL endpoint set to request a certificate would get the
user's proxy certificate (if they set it up to accept anything), or it would
fail with a protocol error (if a specific list of CAs was requested), instead of
prompting the user.

  I don't have a solution for this problem / a way to make this test pass, but I
thought it might help to shake out the problem.

[Ryan Hamilton, 2011-01-10 23:35:53]

Wow!  Yuck!  I think you've definitely uncovered a significant issue :(  From
reading your detailed message of Friday, it sounds like a possible work around
would be to change the way HttpStreamRequest::GenerateSSLParams() is
implemented.  Without thinking this through in much detail, would it be feasible
for HttpStreamRequest to have two different SSLConfig member fields, and then
populate/return the appropriate field.  (Or some such).

Does that sound plausible, or am I missing a subtle detail?

[Ryan Sleevi, 2011-01-10 23:45:31]

Did you mean HttpNetworkTransaction (instead of HttpStreamRequest?)

If so, I was thinking the same thing when I was working through the issue, and I
think that should address the other edge cases I mentioned via e-mail.

However, it would also be necessary to distinguish via some way what the source
of an SSL error is. CLIENT_AUTH_CERT_NEEDED at least implies that host_and_port
will be available via the CertRequestInfo for matching, but other errors that
may require action on the ssl_config may not be (SPDY, NPN, TLS intolerance, bad
client auth)

[Ryan Sleevi, 2011-01-11 23:33:22]

+cc wtc: In response to your comments on http://codereview.chromium.org/6120002/

The ssl_config_ of HttpStreamRequest/HttpNetworkTransaction is currently shared.

[wtc, 2011-01-11 23:49:56]

rsleevi: this is a known weakness of using the same ssl_config
for the HTTPS proxy and destination server.

The solution is to have two ssl_config (at least the send_client_cert
and client_cert fields) structures, similar to the

  scoped_refptr<HttpAuthController>
      auth_controllers_[HttpAuth::AUTH_NUM_TARGETS];

member of HttpNetworkTransaction for HTTP proxy and server auth.