4 ms·

One of our ("tech people") main failures was that, while we made a heavy push for server authentication, we didn't make a similarly strong push for client authe

by cesarb 7y ago

One of our ("tech people") main failures was that, while we made a heavy push for server authentication, we didn't make a similarly strong push for client authentication. With client certificates, MITM like that is not possible, unless the server also trusts the MITM CA to authenticate its clients (and uses a CA for the client certificates in the first place, instead of a direct mapping between users and their certificates).

skela224 7y ago
How would the client certificates be distributed to users in Kazakhstan?
- u801e 7y ago
  You could send them to the email address you used to register the account. Then install it in your browser's or OS' certificate store.
  - haimez 7y ago
    Email is similarly unencrypted by default and can be blocked if encrypted and being used as an active circumvention vector. Yes, mail servers outside the jurisdiction could work until https access to gmail is also blocked- but that’s not outside the realm of possibility (see: China) and also begs the question: how do you get to your secure gmail web interface if you need to receive a secure email before your first login?
zrm 7y ago
Using CAs to authenticate clients is subject to the same attack. They block communication from any client that won't disclose its private key to the MITM box or use it to encrypt/sign whatever the MITM requires it to. You can't have security if you have a MITM that says "compromise your endpoint or we block you" and you concede to that. The only real solutions are either political or making the encrypted traffic look like some permitted traffic. (Or using a different network.)
- u801e 7y ago
  > Using CAs to authenticate clients is subject to the same attack. You don't need to use a publicly available CA to verify client-side certificates. The server could use its own internal CA to sign CSRs from clients and send the reslting certificate back to the client via email or some other means.
  - PeterisP 7y ago
    In which case the MITM will be unable to connect to the server because it won't have the certificate (that you sent via email or some other means), so the service simply won't work. That's the whole point, you either go through MITM or not at all.
  - deleted 7y ago
    [deleted]
jasonh3 7y ago
Somewhat related: if there were a shared password between the client and server, Password Authenticated Key Exchange techniques [0] could offer protection even when the server CA was compromised. PAKEs use zero-knowledge proof techniques to assert that each side already had password material (and derive a key from it) without revealing what the actual password was if the other side didn't have it to begin with. In this case, only connections where a password was already agreed on would be protected vs. general unauthenticated browsing. There was a draft proposal to add PAKE support to TLS 1.3, but it appears to have unfortunately expired [1]. 0: https://en.wikipedia.org/wiki/Password-authenticated_key_agreement https://en.wikipedia.org/wiki/Password-authenticated_key_agr... 1: https://tools.ietf.org/html/draft-barnes-tls-pake-04 https://tools.ietf.org/html/draft-barnes-tls-pake-04
- oneplane 7y ago
  I suppose that'd take something pike obfuscated paper mail password exchange before digital. Or rtty. Or 56k international calls for key setup?
- tialaramex 7y ago
  It died for lack of interest, you can basically watch that happen at IETF 102 here: https://youtu.be/mx40DSeoxnw?t=1230 https://youtu.be/mx40DSeoxnw?t=1230 TLS 1.3 was in some part an exercise in removing crap people thought might be a good idea in earlier versions, but then either never used or turned out to be a terrible idea but was notionally "optional" so you could say to keep using TLS but just disable that feature. So there is skepticism pre-existing in that room against the idea of just adding more stuff than might be cool unless it's clearly _needed_. A feature that keeps six people in Kazakhstan (who happen to have manually pre-configured a PAKE) safe but everybody else is still screwed isn't the sort of impact TLS 1.3 was looking for.

by cesarb 7y ago

skela224 7y ago

How would the client certificates be distributed to users in Kazakhstan?

u801e 7y ago
You could send them to the email address you used to register the account. Then install it in your browser's or OS' certificate store.
- haimez 7y ago
  Email is similarly unencrypted by default and can be blocked if encrypted and being used as an active circumvention vector. Yes, mail servers outside the jurisdiction could work until https access to gmail is also blocked- but that’s not outside the realm of possibility (see: China) and also begs the question: how do you get to your secure gmail web interface if you need to receive a secure email before your first login?

zrm 7y ago

Using CAs to authenticate clients is subject to the same attack. They block communication from any client that won't disclose its private key to the MITM box or use it to encrypt/sign whatever the MITM requires it to. You can't have security if you have a MITM that says "compromise your endpoint or we block you" and you concede to that. The only real solutions are either political or making the encrypted traffic look like some permitted traffic. (Or using a different network.)

u801e 7y ago
> Using CAs to authenticate clients is subject to the same attack. You don't need to use a publicly available CA to verify client-side certificates. The server could use its own internal CA to sign CSRs from clients and send the reslting certificate back to the client via email or some other means.
- PeterisP 7y ago
  In which case the MITM will be unable to connect to the server because it won't have the certificate (that you sent via email or some other means), so the service simply won't work. That's the whole point, you either go through MITM or not at all.
- deleted 7y ago
  [deleted]

jasonh3 7y ago

Somewhat related: if there were a shared password between the client and server, Password Authenticated Key Exchange techniques [0] could offer protection even when the server CA was compromised. PAKEs use zero-knowledge proof techniques to assert that each side already had password material (and derive a key from it) without revealing what the actual password was if the other side didn't have it to begin with. In this case, only connections where a password was already agreed on would be protected vs. general unauthenticated browsing. There was a draft proposal to add PAKE support to TLS 1.3, but it appears to have unfortunately expired [1]. 0: https://en.wikipedia.org/wiki/Password-authenticated_key_agreement https://en.wikipedia.org/wiki/Password-authenticated_key_agr... 1: https://tools.ietf.org/html/draft-barnes-tls-pake-04 https://tools.ietf.org/html/draft-barnes-tls-pake-04

oneplane 7y ago
I suppose that'd take something pike obfuscated paper mail password exchange before digital. Or rtty. Or 56k international calls for key setup?
tialaramex 7y ago
It died for lack of interest, you can basically watch that happen at IETF 102 here: https://youtu.be/mx40DSeoxnw?t=1230 https://youtu.be/mx40DSeoxnw?t=1230 TLS 1.3 was in some part an exercise in removing crap people thought might be a good idea in earlier versions, but then either never used or turned out to be a terrible idea but was notionally "optional" so you could say to keep using TLS but just disable that feature. So there is skepticism pre-existing in that room against the idea of just adding more stuff than might be cool unless it's clearly _needed_. A feature that keeps six people in Kazakhstan (who happen to have manually pre-configured a PAKE) safe but everybody else is still screwed isn't the sort of impact TLS 1.3 was looking for.