In TLS 1.3, most of the handshake is encrypted, which is great. But this means, once TLS 1.3 is widespread and we start needing to debug problems with it, net-internals logs will be pretty much opaque. There's SSLKEYLOGFILE, but asking users for that sounds absurd.

Instead, register the message callback in BoringSSL and put them in NetLog when logging is enabled. This will only contain the handshake transcript, not any private key material.

Even for TLS 1.2, it means we won't have to ask for tcpdumps or net logs with raw byte data for the cases where we just care about the handshake messages. (What extensions were negotiated, etc.)


The one caveat here is client certificates, which we currently do not log. We may wish to redact the client Certificate message. (This would be easy enough to do. Though it does mean we can't check the CertificateVerify signature which I've done on occasion.)

battre: Same question as with issue #674377, but I figure I ought to ask separately about this scenario. For people following the instructions at [0] and attaching logs for us in bug reports, should the client certificate message be included at the default level (where we do not redact URLs but do redact cookies and HTTP credentials)?

Background info: This does not include the private key (needed to impersonate), but does contain the user's public key and also often things like a name, email, organization, etc. In TLS 1.2 this was, despite this, transmitted in plaintext anyway (sigh). TLS 1.3 fixes this and encrypts it.

[0] https://dev.chromium.org/for-testers/providing-network-details