search

hannesm / tlstunnel-lwt

TLS tunnel -- an alternative to stud / stunnel
BSD 2-Clause "Simplified" License
85 stars 7 forks source link

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

Open cfcs opened 8 years ago

cfcs commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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.

The research continues.

hannesm commented 8 years ago

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

hannesm commented 6 years ago

as of 2a9686d8338f1d91669e9b1ed984758237aae380 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 commented 6 years ago

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