NetBSD-Announce archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

NetBSD and the eMudhra CA compromise



As you may have heard, a CA (certification authority) was
compromised[1], enabling adversaries on the network to forge the
identities of servers in TLS sessions.  This is very bad.

We're working on dealing with this in NetBSD and pkgsrc[2].  Until all
the updates are sorted out, in order to make sure applications that
use the system certificate store don't fall for such forgeries, you
can run, as root:

# certctl untrust /usr/share/certs/mozilla/all/Comodo_AAA_Services_root.pem
# certctl untrust /usr/share/certs/mozilla/all/emSign_ECC_Root_CA_-_G3.pem

You can test whether it worked by running:

$ ftp -V -o /dev/null https://dv-g3b-emudhra.we-have-a-problem.com/
$ ftp -V -o /dev/null https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

If either one succeeds, you have a problem.  For more background and
ways to test, see: https://emudhra.we-have-a-problem.com/

Note that certctl(8) does not affect applications which _don't_ use
the system certificate store, and it won't work if you have manually
populated /etc/openssl/certs instead of using certctl(8).  Packages
from pkgsrc that provide or use alternate certificate stores such as
mozilla-rootcerts, py-certifi, golang, and so on, may need to be
updated separately once the updates are ready.


[1] Specifically, it turns out that they chose their private keys at
    random from the interval [0,256) instead of the interval
    [0,115792089210356248762697446949407573529996955224135760342422259061068512044369).
    This deviation from the standard procedure, it turns out, makes
    brute force search for the keys a little bit easier.

[2] PR security/60908: mozilla-certdata: update for compromised CA
    https://gnats.netbsd.org/60908


Home | Main Index | Thread Index | Old Index