Support for client certs in ssl_server_socket.

net/cert/client_cert_verifier.h

Index: net/cert/client_cert_verifier.h
diff --git a/net/cert/client_cert_verifier.h b/net/cert/client_cert_verifier.h
new file mode 100644
index 0000000000000000000000000000000000000000..1f97cbbf718e8dfe0fc29bac392bbe4fdf8d1a39
--- /dev/null
+++ b/net/cert/client_cert_verifier.h
@@ -0,0 +1,25 @@
+// Copyright (c) 2015 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.
+
+#ifndef NET_CERT_CLIENT_CERT_VERIFIER_H_
+#define NET_CERT_CLIENT_CERT_VERIFIER_H_
+
+namespace net {
+
+class BoundNetLog;

[Ryan Sleevi, 2015/12/17 03:47:35]

Unused?

[ryanchung, 2015/12/18 00:00:55]

Done.

+class X509Certificate;
+
+// ClientCertVerifier represents a service for verifying certificates.
+class ClientCertVerifier {
+ public:
+  virtual ~ClientCertVerifier() {}
+
+  // Verifies the given certificate as a client certificate.
+  // Returns OK if successful or an error code upon failure.
+  virtual int Verify(X509Certificate* cert) = 0;

[Ryan Sleevi, 2015/12/17 03:47:35]

DESIGN: Why isn't this interface asynchronous? I think if we're looking to
export/support this API (which I'm not really wanting to, but I guess Cast needs
it), we shouldn't be doing it blocking.

[ryanchung, 2015/12/18 00:00:55]

I believe OpenSSL only supports synchronous client certificate verification at
the moment. http://crbug.com/347402

[Ryan Sleevi, 2015/12/18 00:07:09]

But the Chrome interface should be designed for asynchronicity, and if it gives
an asynchronous result, the binding code (to OpenSSL) should then fail.

But we shouldn't be writing new //net code that assumes synchronous responses,
even if a third-party library demands it. In the worst case, we'd offload the
OpenSSL operation to a dedicated thread, and then spin a waitloop on that thread
to complete the asynchronous operation (this is how we handled NSS callbacks
that demand synchronicity on fundamentally asynchronous events)

[davidben, 2015/12/19 00:24:24]

Teaching BoringSSL to be asynchronous with certificate verification should
certainly be doable. It's one more interface to change later when we rid
ourselves of the legacy X.509 stack, but whatever.

It should also work to do the verification after the handshake, like
SSLClientSocketOpenSSL does. The two subtleties are:

1. Unless you implement the session cache externally, which seems more trouble
than is worth it, the sessions with bad verifications will end up in the session
cache. This is actually just fine *as long as you verify on both new handshakes
and resumptions*.

2. If you don't like the certificate, you'll decide too late to be able to send
an alert to the client. That means that the client won't know to try again. This
may not be something that matters to Cast.


I also don't actually mind making it synchronous to start with. I'm assuming
that Cast's needs for client certificate verification aren't that complex and
won't require anything crazy like AIA chasing. And it'd already have to verify
CertificateVerify signatures synchronously, so if we're only worried about
signature verification, this isn't a big deal.

[ryanchung, 2016/01/14 00:16:40]

I updated the interface. For now, verification will fail if it gives an
asynchronous result.

+};
+
+}  // namespace net
+
+#endif  // NET_CERT_CLIENT_CERT_VERIFIER_H_