
Crypto flaw made it easy for attackers to snoop on Juniper customers - signa11
http://arstechnica.com/security/2016/07/crypto-flaw-made-it-easy-for-attackers-to-snoop-on-juniper-customers/
======
matt_wulfeck
> 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...](http://blog.cryptographyengineering.com/2015/12/on-juniper-
backdoor.html?m=1)

------
po1nter
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-...](http://arstechnica.com/security/2015/12/researchers-confirm-
backdoor-password-in-juniper-firewall-code/)

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

~~~
revelation
One could say it's a backdoor in certificate validation.

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

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

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

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

------
chflags
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](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.

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

