Crypto flaw made it easy for attackers to snoop on Juniper customers

> When a peer device presents a self-signed certificate as its end entity certificate with its issuer name matching one of the valid CA certificates enrolled in Junos, the peer certificate validation is skipped and the peer certificate is treated as valid" [...] This may allow an attacker to generate a specially crafted self-signed certificate and bypass certificate validation.

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

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

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

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.

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.

By snoop, you mean exploit, and violate the draconian CFAA law right? Snoop might be too weak a word?