Landing : Athabascau University

Juniper's products are still insecure; more evidence that the company was complicit / Boing Boing

http://boingboing.net/2016/01/08/junipers-products-are-still.html

So it looks like the backdoor into Juniper firewalls that lets anyone invisibly observe encrypted traffic persists, and it looks more and more like it was an intentional policy. It is hard to fathom why anyone would trust a closed-source product with their security. If you are not allowed to see how it works, how could you ever have faith that something like this won't happen?

Comments

  • Viorel Tabara January 10, 2016 - 1:54pm

    Ouch! Not even fixed yet? I've found this excerpt from OpenConnect main page relevant to all you've mentioned Jon, mainly the last point Wink:

    Development of OpenConnect was started after a trial of the Cisco client under Linux found it to have many deficiencies:

    • Inability to use SSL certificates from a TPM or PKCS#11 smartcard, or even use a passphrase.
    • Lack of support for Linux platforms other than i386.
    • Lack of integration with NetworkManager on the Linux desktop.
    • Lack of proper (RPM/DEB) packaging for Linux distributions.
    • "Stealth" use of libraries with dlopen(), even using the development-only symlinks such as libz.so — making it hard to properly discover the dependencies which proper packaging would have expressed
    • Tempfile races allowing unprivileged users to trick it into overwriting arbitrary files, as root.
    • Unable to run as an unprivileged user, which would have reduced the severity of the above bug.
    • Inability to audit the source code for further such "Security 101" bugs.