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