4 ms·
There's a few problems with it. 1. client auth in TLS1.2 and earlier is done at the wrong time in the handshake. As a result the client's identity (which unli
by ctz 10y ago
There's a few problems with it.
1. client auth in TLS1.2 and earlier is done at the wrong time in the handshake. As a result the client's identity (which unlike the server identity usually identifies a user; see sibling comment which confirms this) is sent in the clear. That's a big privacy failure.
2. to work around (1), some implementations do an initial server-auth handshake, then immediately renegotiate up to mutual-auth (renegotiations are encrypted). Renegotiation has quite a dismal history, and I definitely want to avoid it.
3. as a follow on from (2), the standard never described what implementations are expected to do if client/server identities change during renegotiation. This (partially) resulted in https://mitls.org/pages/attacks/3SHAKE https://mitls.org/pages/attacks/3SHAKE
All of these are fixed in TLS1.3: client identities are encrypted and renegotiation is dropped.
- mcpherrinm 10y agoYeah, trying to make TLS client identity private is a recipe for sadness (well, before 1.3). At least in the environments I use TLS, which is interservice datacenter communications, there are no privacy issues (especially since you can just look at what container a connection comes from for the same amount of identity leaking).
- gue5t 10y agoThank you, this is a very good explanation and now I'm convinced that this is the right thing to do. But I do need mutual authentication, and want to avoid rolling my own crypto for it--so does Rustls expect to support client auth in TLS 1.3 when that spec is finalized and implemented?
- kalkin 10y agoSuper nitpicky, but would it make sense in the README then to specify "client authentication per TLS 1.2 or earlier", as the non-feature, or something like that?