| 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. 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. |