Re: ca-certificates
On Sun, Sep 8, 2013 at 8:47 AM, Gordon Haverland
<ghaverla@materialisations.com> wrote:
> The world is in the process of learning just how much the NSA,
> GCHQ, and the similar organizations of Canada, New Zealand and
> Australia is doing to subvert ALL encrypted traffic. One thing I
> read recently, is that it is possible that the NSA (with the other
> 4 possibly helping) has broken RC4.
Don't worry. It was broken to begin with. See the wikipedia notes:
http://en.wikipedia.org/wiki/RC4
<rant-mode>
Something we have to get used to is that computers are not magic. We
all too often ignore one of the underlying principles of systems --
systems are inherently insecure. Every system is. Before you build it,
you know it will be insecure somewhere. The only question is whether
your mitigating practices will be sufficient in the context in which
the system operates, and the best answer you'll get is, maybe, for a
while.
The best we can get from encryption is to get closer to the levels of
wax seals (ink seals in Asia) in the days of no copying
machines/scanners/3D printers.
And learning how to not waste time securing things that don't need securing.
</rant-mode>
> Today, after an apt-get update, I see there is a new ca-
> certificates available.
Did I miss that?
(And I'm wondering where it would be announced. I don't see any
mention of CA certificates on any debain *-announce lists recently.)
But another big question is, what is telling you new certificates are
available? Apt or something else?
> Okay, install it.
Whoa, there, cowboy, slow down!
> There is a dialog on
> my text console for this, do you trust this handful of new
> certificates?
Nice of whatever it was to give you a chance to change your mind.
> How should I know?
Well, asking on this list is not the best way, but it might help.
> The README file (possibly from
> the June update, since I haven't finished allowing the update to
> install)
Is there a file date on the README file?
But you say June, so let's go checking in all the *-announce lists around June.
I see that debian-devel-announce has a few posts about delegations in
June, including obsolete delegations,
https://lists.debian.org/debian-devel-announce/2013/06/threads.html
anything relevant there?
Doing a search of the web on Google for "new CA certificates for
debian" brings up some possible pages:
http://packages.debian.org/search?lang=en&keywords=ca-certificates
including this one from around June (jessie):
--------------------
http://packages.debian.org/en/jessie/ca-certificates
--------------------
Package: ca-certificates (20130610)
Common CA certificates
This package includes PEM files of CA certificates to allow SSL-based
applications to check for the authenticity of SSL connections.
It includes, among others, certificate authorities used by the Debian
infrastructure and those shipped with Mozilla's browsers.
Please note that Debian can neither confirm nor deny whether the
certificate authorities whose certificates are included in this
package have in any way been audited for trustworthiness or RFC 3647
compliance. Full responsibility to assess them belongs to the local
system administrator.
--------------------
and this one from last week (sid):
--------------------
http://packages.debian.org/en/sid/ca-certificates
--------------------
Package: ca-certificates (20130906)
Common CA certificates
This package includes PEM files of CA certificates to allow SSL-based
applications to check for the authenticity of SSL connections.
It includes, among others, certificate authorities used by the Debian
infrastructure and those shipped with Mozilla's browsers.
Please note that Debian can neither confirm nor deny whether the
certificate authorities whose certificates are included in this
package have in any way been audited for trustworthiness or RFC 3647
compliance. Full responsibility to assess them belongs to the local
system administrator.
--------------------
> says that there is only a single way for updates to get
> into the Debian system, they must be updates to Mozilla's trust
> system. Wonderful, how do we evaluate that?
I would sure like to know what directory that README is sitting in.
> As the package is not yet installed, I don't know if there is a
> changelog entry explaining where these new certificates come from,
> and why we should trust them. But, the changelog entry from June
> says that in that update, they are removing an expired
> certificate from 2007. Is this SOP? Wait 6 years to remove an
> expired certificate?
Generally, you don't really want to remove certificates. Move them to
the expired list or the broken (invalidated) list or the
I-do-not-want-to-trust-this list or such, but not remove them. And the
local administrator (machine owner/user) should decide when, but may
need to be reminded after a while.
> The certificate knows it is expired.
Certificates have developed sentience?
> Every time I apt-get update,
> I get pestered about problems with the QGIS archive key. I tried
> doing key maintenance with apt-key. All I did was change the
> error message I get from apt-get update.
Specific messages? Log entries?
> Maybe when the current
> QGIS key expires, the update to that will start to work again?
>
> It would be nice if say the README.Debian file would provide
> pointers to tools or protocols to evaluate these certificates.
If I get on my high-horse and say you should know how to do this, I'll
get shot down. (I am not yet familiar with all the tools on debian,
myself.) Let's both fix that. It's basic stuff.
> But, if the NSA has broken RC4 and someone can prove it, I would
> imagine that most certificates in ca-certificates should become
> invalid very soon.
Say debian has to invalidate them? Then what?
> But, cryptanalysis is not my field. Numerical methods is a big
> chunk of my study.
>
> Gord
Numerical methods is not the issue here. RC4 has been broken for a
long time, ssl is and has been very vulnerable. We use them carefully,
with various mitigation techniques.
NSA has not beaten prime numbers in general, although they have
subverted some of the constants currently in use. I assume there are a
number of infrastructure team members checking that the mitigations
currently in use are sufficient.
But for your present question, we need more information to be able to
respond with anything more meaningful than my rantings, above.
--
Joel Rees
Reply to: