4 ms·

> The following things are broken, obsolete, badly designed, underspecified, dangerous and/or insane. Rustls does not support [...]

johncolanduoni 10y ago
I'd love to see an explanation for not supporting client authentication. Also, completely ruling out discrete-log DH and requiring PFS is not feasible unless you want to rule out a lot of clients and servers, on top of not supporting TLS 1.1.
- sdegutis 10y ago
  I've never even heard of client authentication until recently. That's probably why.
  - stormbrew 10y ago
    Obscure is not on the list in GP's quote, and afaik client authentication is none of the things in that list. It's actually used a fair bit in uses of TLS that are not the open web.
    - bluejekyll 10y ago
      Yes. I've implemented client-auth with a private CA, specifically to authenticate services to each other. It's a very handy tool when you have disparate networks.
    - spilk 10y ago
      Coming from a US DoD background, TLS client authentication is mandated for nearly everything. Everyone carries keypairs around their neck on their ID card (PIV smartcard with x.509 certificates)
  - johncolanduoni 10y ago
    If you've ever used OpenVPN, you've used TLS client authentication. That seems like a pretty huge hole to purposely put in your feature set. I understand not implementing it yet because it's more work, but I don't get drawing a line in the sand.
- markus2012 10y ago
  Where I work client auth is used for a good (and growing) number of internal services. Client auth is simple to use - our internal services are given the username from the CN, which they use to perform authorization checks. For a lot of simple internal services that don't require two-factor auth it works great. Am I missing something better? (We already have the infrastructure in place to deal with client keys)
- adekok 10y ago
  > I'd love to see an explanation for not supporting client authentication. My guess? They don't use it in their applications, so they don't think anyone else uses it, either. TLS client authentication is widely used in 802.1X (WiFi and wired) authentication. I've seen it used in a lot of other situations, e.g. web client access (client cert + user password), LDAP client access, etc. Maybe there are security issues in client authentication which they're aware of. If so, they should share them. But simply labeling client authentication as "obsolete" shows a close-minded attitude.
- vostok 10y ago
  It seems especially wrongheaded as client certificates are used in certain academic environments.
- 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 ago
    Yeah, 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 ago
    Thank 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 ago
    Super 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?
michaelmior 10y ago
That comment is intended to say that Rustls doesn't support the things in the list below because the technologies in that list are broken, not because Rustls itself is broken. So the authors have chosen just not to implement anything in that list.
- sdegutis 10y ago
  Right, hence "modern".

johncolanduoni 10y ago

I'd love to see an explanation for not supporting client authentication. Also, completely ruling out discrete-log DH and requiring PFS is not feasible unless you want to rule out a lot of clients and servers, on top of not supporting TLS 1.1.

sdegutis 10y ago
I've never even heard of client authentication until recently. That's probably why.
- stormbrew 10y ago
  Obscure is not on the list in GP's quote, and afaik client authentication is none of the things in that list. It's actually used a fair bit in uses of TLS that are not the open web.
  - bluejekyll 10y ago
    Yes. I've implemented client-auth with a private CA, specifically to authenticate services to each other. It's a very handy tool when you have disparate networks.
  - spilk 10y ago
    Coming from a US DoD background, TLS client authentication is mandated for nearly everything. Everyone carries keypairs around their neck on their ID card (PIV smartcard with x.509 certificates)
- johncolanduoni 10y ago
  If you've ever used OpenVPN, you've used TLS client authentication. That seems like a pretty huge hole to purposely put in your feature set. I understand not implementing it yet because it's more work, but I don't get drawing a line in the sand.
markus2012 10y ago
Where I work client auth is used for a good (and growing) number of internal services. Client auth is simple to use - our internal services are given the username from the CN, which they use to perform authorization checks. For a lot of simple internal services that don't require two-factor auth it works great. Am I missing something better? (We already have the infrastructure in place to deal with client keys)
adekok 10y ago
> I'd love to see an explanation for not supporting client authentication. My guess? They don't use it in their applications, so they don't think anyone else uses it, either. TLS client authentication is widely used in 802.1X (WiFi and wired) authentication. I've seen it used in a lot of other situations, e.g. web client access (client cert + user password), LDAP client access, etc. Maybe there are security issues in client authentication which they're aware of. If so, they should share them. But simply labeling client authentication as "obsolete" shows a close-minded attitude.
vostok 10y ago
It seems especially wrongheaded as client certificates are used in certain academic environments.
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 ago
  Yeah, 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 ago
  Thank 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 ago
  Super 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?

michaelmior 10y ago

That comment is intended to say that Rustls doesn't support the things in the list below because the technologies in that list are broken, not because Rustls itself is broken. So the authors have chosen just not to implement anything in that list.

sdegutis 10y ago
Right, hence "modern".