Crypto flaw made it easy for attackers to snoop on Juniper customers(arstechnica.com)
arstechnica.com
Crypto flaw made it easy for attackers to snoop on Juniper customers
http://arstechnica.com/security/2016/07/crypto-flaw-made-it-easy-for-attackers-to-snoop-on-juniper-customers/
6 comments
This is the same company that has a hard coded root password into their firmwares[1] (a backdoor you might say).
1. http://arstechnica.com/security/2015/12/researchers-confirm-...
1. http://arstechnica.com/security/2015/12/researchers-confirm-...
This isn't a "crypto flaw" at all. It's a flaw in common name validation that circumvents the normal CA trust chain.
So I'd say it's worse than a crypto flaw since it's much easier to exploit. And there was code explicitly written to circumvent the normal path.
So extra work had to be done in order to make things less secure. That's the reverse of what you'd normally expect, which is that security flaws arise from organizational or individual "laziness."
So I'd say it's worse than a crypto flaw since it's much easier to exploit. And there was code explicitly written to circumvent the normal path.
So extra work had to be done in order to make things less secure. That's the reverse of what you'd normally expect, which is that security flaws arise from organizational or individual "laziness."
One could say it's a backdoor in certificate validation.
I wouldn't call it a backdoor because it's such a simple and obvious bug, in no way hidden or obfuscated. It's just an utter catastrophe of design, to check the name on the certificate instead of the signature.
Yeah that is exactly what they want you to think!
"Oh it can't be a backdoor as it was so obvious it was just a mistake". Hmmmmmmm.
"Oh it can't be a backdoor as it was so obvious it was just a mistake". Hmmmmmmm.
Even if it's intentional, at some point of obviousness it starts being a front door.
They already have multiple backdoors and they have a proven history of poor implementation.
They already have multiple backdoors and they have a proven history of poor implementation.
I saw that whoever still trusts Juniper after the discovery of the NSA backdoor, deserves all data breaches they're going to get going forward.
[deleted]
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.
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.
By snoop, you mean exploit, and violate the draconian CFAA law right? Snoop might be too weak a word?
Specially crafted? Sounds like the name just needs to be *.juniper.com.
Not surprising given the company also used Dual_EC_DRBG with its own who-knows-what-or-why prime [1]. I don't see any reason to trust the technical competency of this company and I'm ashamed to know they are a supplier of US government switching hardware.
1. http://blog.cryptographyengineering.com/2015/12/on-juniper-b...