Implement Token Binding negotiation TLS extension

net/ssl/ssl_info.h

Index: net/ssl/ssl_info.h
diff --git a/net/ssl/ssl_info.h b/net/ssl/ssl_info.h
index 28ce82d0ae6cb1ddf7a20f6ab9fd47dfe6075903..f22adaf0df6be82090c4df34365bd49eab10f386 100644
--- a/net/ssl/ssl_info.h
+++ b/net/ssl/ssl_info.h
@@ -82,6 +82,10 @@ class NET_EXPORT SSLInfo {
   // True if a channel ID was sent to the server.
   bool channel_id_sent;
 
+  // True if Token Binding was negotiated with the server and we agreed on a
+  // version and key params.
+  bool token_binding_negotiated;

[davidben, 2015/09/25 21:51:50]

We'll need the TB type, won't we? The HTTP layer is going to be interpreting it.

[nharper, 2015/09/28 21:43:39]

The http layer needs the TokenBinding (i.e. public key and signed material from
ekm). My current approach (in a subsequent CL) is to add a method to
SSLClientSocket GetProvidedTokenBinding, which returns a const-ref to a string
containing the TokenBinding, and SSLClientSocketOpenSSL has a member variable
provided_token_binding_ which gets filled at the end of a successful
negotiation. I think the http layer only needs that method, and what's in
SSLInfo is fine.

[davidben, 2015/10/01 16:15:17]

I'm not sure I follow. My understanding here is that we explicitly don't want to
have to split HTTP2 sessions along TB decisions, which is why the TLS extension
only does a very uninteresting non-variable negotiation and then everything else
is done on a per-request basis.

Hence why the key lookup should happen externally and such. SSLClientSocket need
only give you an API to extract the tls-unique.

[nharper, 2015/10/01 19:12:23]

The draft spec for Token Binding over HTTP
(https://tools.ietf.org/html/draft-ietf-tokbind-https-01#section-2) states that
once a client and server have negotiated Token Binding, clients MUST include the
Sec-Token-Binding header in their HTTP requests. I interpret this to mean that a
TLS connection cannot be used both with and without Token Binding. My
understanding is that moving things to the application layer for Token Binding
(compared to Channel ID) wasn't to make decisions (like whether or not to allow
Token Binding) on a per-request basis, but was to allow for things like the
federated use case, where an application layer decision results in forwarding
the token binding from one origin to another origin.

I think having the key lookup in the SSLClientSocket is perfectly reasonable. An
SSLClientSocket is used for only one origin, and the keys are per origin. Also,
the negotiation for what key params to use (and whether or not to use Token
Binding at all) happens at the transport layer.

The logic at the application layer is about which token bindings to include. The
spec requires that it always send the provided token binding; the decision made
by the application layer is which referred token bindings to include. At the
application layer, it can treat all token bindings as opaque byte strings. Since
the SSLClientSocket has all of the necessary info to build the provided token
binding, I think it makes more sense for it to be built there and let the
application layer treat it as an opaque byte string.

The API that I am trying to expose to the application layer is
1) Is Token Binding Enabled?
2) What is the provided token binding?

[davidben, 2015/10/01 19:20:12]

Due to CORS, we end up in situations where we must assert credentials on some
connections, but not otherwise.

It's also not true that an SSLClientSocket is used for only one origin. We will
happily coalesce them by origins for SPDY if the certificates allow it. There's
also Alt-Svc whose entire purpose in life is to coalesce more things like that.

+
   HandshakeType handshake_type;
 
   // The hashes, in several algorithms, of the SubjectPublicKeyInfos from