Implement Token Binding negotiation TLS extension

net/ssl/ssl_config.cc

 // Copyright 2014 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 "net/ssl/ssl_config.h"
 
 #include "net/cert/cert_verifier.h"
 
 namespace net {
 
@@ skipping 16 matching lines @@
       deprecated_cipher_suites_enabled(false),
       rc4_enabled(false),
       channel_id_enabled(true),
       false_start_enabled(true),
       signed_cert_timestamps_enabled(true),
       require_ecdhe(false),
       send_client_cert(false),
       verify_ev_cert(false),
       version_fallback(false),
       cert_io_enabled(true),
-      renego_allowed_default(false) {}
+      renego_allowed_default(false) {
+  token_binding_params.push_back(TB_PARAM_ECDSAP256);

[nharper, 2015/10/31 02:01:23]

I have 2 new fields in SSLConfig: token_binding_enabled, and
token_binding_params. The former defaults to false (off). The behavior that
makes most sense to me is that a user of token binding (e.g.
HttpNetworkTransaction) only needs to flip token_binding_enabled, so I'm setting
token_binding_params to a default here. I imagine in the future when we support
multiple key params I'll modify SSLConfigServiceManagerPref to control set
token_binding_params based on some future switch to enable a new param.

Other options I could do with this:
* set token_binding_params in SSLConfigServiceManagerPref now (so that in
SSLConfig it's initialized to an empty vector)
* rip out token_binding_params completely for now (and add it back when there
are multiple supported params)

[davidben, 2015/11/04 00:40:36]

I think I would do one of:

- Caller sets bool token_binding_enabled and SSLClientSocketOpenSSL interprets
that to mean advertise the one and only configuration.

- Caller sets a std::vector token_binding_params in full glory.

The interpretation of the former would be roughly what this is now, but without
the unnecessary member in SSLConfig. "TB in SSLClientSocket means supporting
TB_PARAM_ECDSAP256, end of story."

The latter would be "TB in SSLClientSocket means you give me a list of TB_PARAM
values and I'll tell you which it chose. It's your problem which key types you
support".

The latter is probably better? I still don't think SSLConfigServiceManagerPref
should have anything to do with it. SSL has no clue where the keys come from or
anything. Only HttpNetworkTransaction or other HTTP bits would know that our key
store is capable of doing RSA keys or P-256 keys or whatever. So it should be a
configuration at the HTTP layer.

That is, when we get around to adding RSA keys, it's still not going to be an
SSL-level config. It's going to be a question of whether the key store (an
consumer-only notion) enables RSA keys or not. The SSL code is purely a blind
pass-through.

[nharper, 2015/11/04 02:28:04]

The latter sounds reasonable to me.

+}
 
 SSLConfig::~SSLConfig() {}
 
 bool SSLConfig::IsAllowedBadCert(X509Certificate* cert,
                                  CertStatus* cert_status) const {
   std::string der_cert;
   if (!X509Certificate::GetDEREncoded(cert->os_cert_handle(), &der_cert))
     return false;
   return IsAllowedBadCert(der_cert, cert_status);
 }
@@ skipping 17 matching lines @@
   if (verify_ev_cert)
     flags |= CertVerifier::VERIFY_EV_CERT;
   if (cert_io_enabled)
     flags |= CertVerifier::VERIFY_CERT_IO_ENABLED;
   if (rev_checking_required_local_anchors)
     flags |= CertVerifier::VERIFY_REV_CHECKING_REQUIRED_LOCAL_ANCHORS;
   return flags;
 }
 
 }  // namespace net