[Pkg-openssl-devel] Bug#642314: Bug#628780: Wrong hash link to cacert.org.pem and wron certificat hash handling at all

[Loïc Minier]

On Wed, Sep 21, 2011, Klaus Ethgen wrote:
> Hmm.. I think, certificates on unix with CRLF line ending is broken and
> should be fixed.

 You mean people should not use CRLF in their certificates when running
 Debian?  Or you mean we should fix support for CRLF in certificates?  I
 have absolutely no doubt that we should do the latter, and the former
 isn't really Debian's choice.

 Note that I opened Debian #642314 specifically for this part of the
 problem, so we can discuss the fixes there.

> > a) link_hash_cert() only searches for "BEGIN CERTIFICATE", not for
> >    "BEGIN X509 CERTIFICATE" or "BEGIN TRUSTED CERTIFICATE" which are
> >    allowed in other parts of the file
> I didn't see certificates with that strings. However, a fix would be
> easy.

 Search for BEGIN in the script:
                if(/^-----BEGIN (.*)-----/) {
                        my $hdr = $1;
                        if($hdr =~ /^(X509 |TRUSTED |)CERTIFICATE$/) {

 the same certificates should be supported consistenly across the whole
 script.

 Debian packages might not ship any such certificates, but people
 running Debian might run c_rehash on these certificates.

> > b) this requires a tempdir with write permissions, which might be a
> >    problem for certain deployments calling c_rehash
> 
> That is true. I think that a unix (linux) system without temp directory
> is not supported. There are many stuff that doesn't work without.

 This is not about the c_rehash run triggered by ca-certificates; this
 is about the c_rehash uses as a binary provided by openssl for whatever
 purpose people need.  c_rehash might be used in minimal chroots, lxc
 containers, with SElinux turned on etc.  The new script now requires
 being able to write files (to a tmpdir), which is completely new.  This
 is not dramatic, but we're speaking of a piece of software which is
 used for mission-critical security questions in plenty of places.
 Security stuff tends to be done in very locked down environments with
 weird constraints.

> Moreover the temp directory that is needed for this patch is only needed
> on c_rehash run, not on the normal system work.

 (this is not about the c_rehash runs during package installation)

> > c) this causes a lot of writes (each certificate is written to a
> >    tempfile which gets deleted); again, this might be a problem if some
> >    deployments run c_rehash on a large number of certificates
> 
> As I told above I do not think that this is an issue as you normally do
> the c_rehash work only once upon a time but use the links much often.

 (this is not about the c_rehash runs during package installation)

 I hadn't timed it, but with openssl_1.0.0d-3.dsc on a modest set of 159
 certs and with a SSD disk:
 time c_rehash . >/dev/null
 c_rehash . > /dev/null  0,02s user 0,10s system 10% cpu 1,145 total

 With the new patched c_rehash:
 c_rehash . > /dev/null  0,63s user 0,62s system 31% cpu 3,909 total

 this is completely non-scientific, but I imagine it would be bad if
 this was a system to install the client certificates to e.g. access
 apache or an openvpn site or an imap server and that it was running
 over say 10 000 certificates for 10 000 employees every hour.

> And there are stuff that is using much more resources than this c_rehash
> on certificate installation (namely the fsync stuff in apt that is
> making it really slow but that's another story).

 (this is not about the c_rehash runs during package installation)

> >  I'm particularly worried about c) because the whole point of c_rehash
> >  is to speed up lookup when there is a large number of certificates
> >  (e.g. client certificates).  If there is a large number of
> >  certificates, then writing each of them to a tempfile is going to be
> >  time consuming.  If there are many certificates, one can also imagine
> >  that certificates are added/removed frequently, requiring frequent runs
> >  of c_rehash.
> 
> Common, I do not think that you add and remove certificates such often.
> Certificates have a validity range in years, not in hours.

 (this is not about the c_rehash runs during package installation)

> >  The root problem here is really that the openssl command-line doesn't
> >  support multiple certificates in a single file,
> > so why not fix that instead?
> 
> could be a long term fix. But I do not think that debian should go a
> lonesome way in this case. It could be interesting for upstream too.

 Absolutely, another reason why I'd prefer that route too; actually I
 wanted to ask whether the c_rehash changes for multiple certificates in
 one file were sent upstream?

> >  * split cacert.org.crt in two files, one per certificate; this would
> >    also allow administrators to enable certificates selectively in
> >    /etc/ca-certificates.conf
> 
> That is only one part of the solution. And the cacert certificate was in
> two files in elder times. (Before etch I think; knows the devil why it
> went to just one file.)

 (I just asked pkern who uploaded the new cacert.crt.)

> >  * document the limitation in openssl / ca-certificates that only the
> >    first certificate gets picked up
> 
> A bad choice. In the particular case of cacert the most used certificate
> is the second one. This ends in the fact that cacert is useless at all
> in debian.

 This is on top of the earlier change, most notably for sysadmins
 installing their own local certificates.

> >  * optionally, we could let ca-certificates or c_rehash fail (if some
> >    flag is set and) if multiple certificates are in a single file
> 
> The same bad choice.

 (same reason)

> - Tune c_rehash the way that it fulfils the mentioned issues. (Should be
>   easy)

 Doesn't hurt; it would be best for the result to be upstreamable so
 that c_rehash behaves the same upstream and in Debian and derivatives.

> - Have two c_rehash tools. One for the users that want only hash one
>   certificate per file and one for apt. That might be a bad solution as
>   the one would remove the links from the other.
> - Introduce a complete new tool that handle the hashes. (Maybe in
>   combination with the submitted fix of x509.)

 This does feel a bit weak, but it might be less problematic than
 changing the c_rehash behavior.  Alternatively, having a flag to
 c_rehash to do different things might be a way to keep a single code
 base and support the two use cases.  update-ca-certificates would call
 "c_rehash --multiple-certs-per-file" or something like that.

> Well, and it should not gets into oblivion that there are two
> alternative method's to calculate the hash. (-subject_hash and
> -subject_hash_old) I think they must be created both.

 Yes; that one actually worried me because the compat links are created
 after the new style links, but it should be ok because in the case of
 conflicts the suffix gets incremented.

> Sorry that I do not see the relevance of your case 'c'. I really do not.

 I suspect you're thinking as c_rehash as a tool used only by
 ca-certificates, when it's actually a general purpose tool; one can
 point openssl or other software like postfix, apache etc. at a CApath
 c_rehash-ed directory.  People doing this are precisely the ones with a
 lot of certificates there, which means they get updated frequently.

-- 
Loïc Minier