Add option to renegotiate before client cert auth to hide cert ID

[cfcs]

It would be nice to conceal the identity of a client certificate by forcing a renegotiation before the client sends the cert.

I'm not so acquainted with the internals of TLS 1.2 - does this method require cooperation from the client?

[hannesm]

I agree that this behaviour should be supported, but am not sure where authentication should take place. Tlstunnel itself atm does not expose TLS session data (including client certificate information) to the backend server (maybe it should, but is there a protocol for this?).

First of all, OCaml-TLS does not (yet!) have an API to do post-handshake authentication properly (but I've a partial implementation for this already, since 1.3 will have explicit support for this). One of the tor handshakes does client authentication over the encrypted channel.

In TLS 1.2, the server can ask the client at any time (e.g. immediately after the initial handshake) to start a renegotiation (by sending a HelloRequest), during which the server can demand (via a CertificateRequest) a client certificate [but it is unclear whether clients have renegotiation enabled]. In TLS 1.3, the server can send a CertificateRequest at any point in time (since only ClientHello and ServerHello are unencrypted in 1.3, there's no need to do post-handshake authentication if you always require an authenticated client).

[cfcs]

Apache and Nginx have configuration/modules to do it by setting HTTP headers, but I believe it's endpoint/protocol-specific, and HTTP headers are not ideal as setting those requires parsing pipelined HTTP requests correctly (a lot of work).

I would personally like to add this behaviour when implementing the ratbox ssld protocol to permit TLS client certificate auth on IRC, but I hope there can be other uses.

I'm looking for other protocols to achieve this, currently I've only found gss-proxy (from Fedora, wire format for delegated GSS-API interactions). It is a bit unclear to me how much of this is tied to Kerberos, but it looks like TLS can also be used.

• gss-proxy page
• presentation about gss-proxy
• gss-proxy wire format

The research continues.

[hannesm]

does the ratbox already have a way to communicate the client authentication information from the TLS endpoint to the plain server?

[hannesm]

as of 2a9686d there's now client authentication, but this information is not forwarded to the backend. happy to get a PR which embeds the client authentication information in whatever protocol is widely used (maybe gss-proxy is the way to go).

[cfcs]

As of March last year it looks like HAProxy can convey this information: http://www.haproxy.org/download/1.8/doc/proxy-protocol.txt