Mailing-List: contact bugs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache HTTPD Bugs Notification List" <bugs@httpd.apache.org>
Date: Thu, 31 Mar 2011 21:13:42 -0400 (EDT)
Message-Id: <201104010113.p311DgfN000406@thor.apache.org>
From: bugzilla@apache.org
To: bugs@httpd.apache.org
Subject: DO NOT REPLY [Bug 40312] ssl_engine_init.c, ssl_init_ctx_verify
 contains a never-true if condition.
In-Reply-To: <bug-40312-7868@https.issues.apache.org/bugzilla/>
References: <bug-40312-7868@https.issues.apache.org/bugzilla/>
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0

https://issues.apache.org/bugzilla/show_bug.cgi?id=40312

--- Comment #4 from tlhackque@yahoo.com 2011-03-31 21:13:40 EDT ---
1) This seems to be the same issue raised in  bug #47329.  I, too, lost hours
debugging the same problem with a TRUSTED certificate.

2) Bug #47329 contained a suggested patch (by jorton, modified by me) that was
never committed.

3) The code added here only reports an error in one of two cases.

Your analysis indicated that the directory case should continue to fail
silently because other files can exist in that directory.  I don't think this
is right.  If a directory contains hundreds of files, debugging a problem where
just one or two fail to load will be at least as painful as the case that you
fixed.  We can do better.

I believe that the only other files that can legitimately be in a certificate
directory are CRLs and hash symlinks.  Note that c_rehash will complain if any
other type of file is found.

Hash symlinks for certificates are exactly 8 hex digits, '.', and a decimal
sequence number.  Filenames of this form can be ignored since the file that
they point to will be in the same directory.  (At least if the standard
c_rehash utility is used.  I suppose someone could be 'clever' and separate
them.)  Ignoring them has the advantage that we will only read the file once,
rather than processing it twice and discarding the duplicates...

Hash symlinks for CRLs are exactly 8 hex digits, '.r', and a decimal sequence
number. Filenames of this form can be ignored since we aren't loading CRLs.

A file can contain any number of certificates and/or CRLs.  I don't think
there's a way to identify what's in a file without reading it and looking for
the '^-----BEGIN (((TRUSTED|X509) CERTIFICATE)|X509 CRL)----- line(s).

A file that doesn't contain at least one of these tags doesn't belong in the
directory, and we should log an error.  (It's probably corrupt, in DER format,
a key or some other data.  Again, c_rehash would whine in this case.)

A file that contains just 'X509 CRL' lines can be silently ignored.

Otherwise, the file claims to contain one or more certificates, and we can ask
OpenSSL to read it.  Any error returned by OpenSSL should be logged...

It's too bad that OpenSSL doesn't provide a sufficiently detailed error code to
avoid the need for mod_ssl to prescan the file, but that's life.  

This wouldn't be as inefficient as it seems; currently we're asking OpenSSL to
process each file twice (once via symlink, once as a regular file).  And these
are likely to be a good distance apart because of the names.  Scanning to
classify first is only a string search on each line (not base64/ASN.1 decode,
etc), and OpenSSL will almost certainly find the data in the buffer cache for
the files we select.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org