The traffic between the attacker and the private network would have been properly encrypted.
Assuming they chose a sensible cipher suite, where is the "crypto flaw"?
Maybe the problem is not the crypto but the strange system devised for authentication of an endpoint.
I call this x509. In my opinion this bizarre^1 "trust model" dating back to a long past era in computing is one of the reasons why MITM on SSL/TLS^2 in today's world of computing is so easy. The other reason is the trust placed in domainnames over IP numbers. Both are systems that delegate "authority" to third parties.
OpenSSH can use x509 for authentication but by default it does not. It uses host keys. Maybe it's not even a "default" but it is the traditional usage.
CurveCP also uses keys instead of certifcates.
The big difference in my view is that x509 relies on the idea of a "certificate authority" or "CA" that "issues" certificates for users.
Host keys require no such authority -- users generate their own.
With x509, there is a reliance on third parties that somehow are deemed "trusted". Host keys require no third parties and therefore no added layers of trust.
Certificates are a business^3. Host keys, to my knowledge, are not.
3. This is starting to change so that certificates can be "free" like host keys. I'd argue it is still a business however, due to the third party involvement in the process.
The widespread use of "self-signed certificates" seems to be an illustration of the desire by users to use certificates like host keys -- i.e., without needing a third party "authority" to "issue" them.
Assuming they chose a sensible cipher suite, where is the "crypto flaw"?
Maybe the problem is not the crypto but the strange system devised for authentication of an endpoint.
I call this x509. In my opinion this bizarre^1 "trust model" dating back to a long past era in computing is one of the reasons why MITM on SSL/TLS^2 in today's world of computing is so easy. The other reason is the trust placed in domainnames over IP numbers. Both are systems that delegate "authority" to third parties.
1. https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt
2. Or perhaps an attack like the one here.
OpenSSH can use x509 for authentication but by default it does not. It uses host keys. Maybe it's not even a "default" but it is the traditional usage.
CurveCP also uses keys instead of certifcates.
The big difference in my view is that x509 relies on the idea of a "certificate authority" or "CA" that "issues" certificates for users.
Host keys require no such authority -- users generate their own.
With x509, there is a reliance on third parties that somehow are deemed "trusted". Host keys require no third parties and therefore no added layers of trust.
Certificates are a business^3. Host keys, to my knowledge, are not.
3. This is starting to change so that certificates can be "free" like host keys. I'd argue it is still a business however, due to the third party involvement in the process.
The widespread use of "self-signed certificates" seems to be an illustration of the desire by users to use certificates like host keys -- i.e., without needing a third party "authority" to "issue" them.