Support for client certs in ssl_server_socket.

net/url_request/url_request_unittest.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include <utility>
 
 #include "build/build_config.h"
 
 #if defined(OS_WIN)
 #include <windows.h>
@@ skipping 8267 matching lines @@
     EXPECT_FALSE(d.received_data_before_response());
     EXPECT_EQ(0, d.bytes_received());
 
     // Send no certificate.
     // TODO(davidben): Get temporary client cert import (with keys) working on
     // all platforms so we can test sending a cert as well.
     r->ContinueWithCertificate(nullptr, nullptr);
 
     base::RunLoop().Run();
 
+    // Client certs is required but none is sent
     EXPECT_EQ(1, d.response_started_count());
     EXPECT_FALSE(d.received_data_before_response());
-    EXPECT_NE(0, d.bytes_received());
+    EXPECT_EQ(0, d.bytes_received());

[davidben, 2016/01/25 20:56:12]

You change the test from successfully connecting to failing to connect, so
you're stressing a bit less of the state machine now. I think we should still
have a test which authenticates with no certificate. This is a terrible idea for
servers to do, but people do do optional client auth for better or worse.

(Also if the test were intended to fail, it needs to assert on the error code
and not just check bytes_received.)

[ryanchung, 2016/01/29 23:22:14]

If we want to support optional client certificates, we need to add another flag
to SSLServerConfig... something like optional_client_cert which will do the same
thing as require_client_cert but doesn't set SSL_VERIFY_FAIL_IF_NO_PEER_CERT. Is
this what you have in mind?

[davidben, 2016/02/04 00:40:11]

Oh hrmf, did I ask you do remove that from a previous version? Sorry! :-( Hard
to remember global requirements.

We probably do want to be able to test that we don't screw this up.
ERR_SSL_PROTOCOL_ERROR could also mean "you spoke the protocol wrong and messed
something up". Maybe an enum? That's what Go's TLS library does:
https://golang.org/pkg/crypto/tls/#ClientAuthType

enum ClientCertType {
  NO_CLIENT_CERT,
  OPTIONAL_CLIENT_CERT,
  REQUIRE_CLIENT_CERT,
};

ClientCertType client_cert;

Or a pair of booleans works too. I don't have hugely strong opinions. svaldez,
do you care? I think my default would be to go with an enum, but if anyone else
cares, go with that.

[ryanchung, 2016/02/05 01:56:13]

Ok, using a enum. I changed the test back to what it was originally.

   }
 }
 
 TEST_F(HTTPSRequestTest, ResumeTest) {
   // Test that we attempt a session resume when making two connections to the
   // same host.
   SpawnedTestServer::SSLOptions ssl_options;
   ssl_options.record_resume = true;
   SpawnedTestServer test_server(
       SpawnedTestServer::TYPE_HTTPS,
@@ skipping 1467 matching lines @@
   AddTestInterceptor()->set_main_intercept_job(std::move(job));
 
   req->Start();
   req->Cancel();
   base::RunLoop().RunUntilIdle();
   EXPECT_EQ(URLRequestStatus::CANCELED, req->status().status());
   EXPECT_EQ(0, d.received_redirect_count());
 }
 
 }  // namespace net