Bug 57553 - mod_ssl_ct causes connection failures when configured 'empty'
Summary: mod_ssl_ct causes connection failures when configured 'empty'
Status: REOPENED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl (show other bugs)
Version: 2.5-HEAD
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-09 15:17 UTC by Tom Ritter
Modified: 2016-07-05 11:43 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Ritter 2015-02-09 15:17:09 UTC
I'm running mod_ssl_ct on 2.4 backport, as described here: https://github.com/trawick/ct-httpd/tree/master/src/2.4.x

I set up a benign configuration, that is, as far as I can understand that shouldn't do anything.  Specifically:

CTAuditStorage /run/ct-audit
CTSCTStorage   /run/ct-scts
CTStaticSCTs /etc/apache2/ssl/rittervg-leaf.cer /etc/apache2/ssl/scts

All directories start off empty, I have two SSL sites enabled, one is ritter.vg the other crypto.is. After running a little bit:

 - ct-audit gets a couple audit_XXXX.tmp files
 - ct-scts gets two directories, one with servercerts.pem the other with servercerts.pem and collated.tmp
 - /etc/apache2/ssl/scts remains empty

I get the following Apache error that causes connection failures in Chrome:

(2)No such file or directory: AH02779: couldn't read /run/ct-scts/4c3fbfbac7589ee68d753f806acc822cbd5082c735fdc3fce3924dc32959288f/collated

(I get back a Close notify alert, attempt to fallback to TLS 1.1 which fails because I'm running an OpenSSL that doesn't permit that.)
Comment 1 Tom Ritter 2015-02-19 06:01:39 UTC
I was able to trace this down a little further, but I'm not terribly familiar with Apache modules.  I have two VHOSTs, defined as listening on separate IP addresses.  And I confirmed that refresh_all_scts() is only iterating over the first VHOST, although I'm not sure why.
Comment 2 Tom Ritter 2015-02-20 02:10:07 UTC
Okay, I tracked it down and figured it out.  look_for_server_certs() is called multiple times for multiple VHOSTs, but is not set up for that.  Specifically, sconf->server_cert_info = apr_array_make(p, 2, sizeof(ct_server_cert_info)); overwrites the initial allocation.  (Leaking memory in the process.)

I don't know what the 'correct' fix for this, you'd probably allocate one slot and then grow the array on subsequent calls, but I don't know how to do that. I did a simple fix  by just putting a if(!sconf->server_cert_info) in front of it and making it allocate 4 slots instead of 2.
Comment 3 Jeff Trawick 2015-02-20 11:38:29 UTC
Thanks for tracking that down.  I'll try (again) to catch up with you today or tomorrow.
Comment 4 Jeff Trawick 2015-02-22 22:30:47 UTC
This should be fixed now by trunk revision r1661540.

http://svn.apache.org/viewvc?view=revision&revision=1661540

The issue I found was that each vhost would not be using its own module configuration (i.e., "sconf" in the previous discussion) if the vhost didn't contain mod_ssl_ct directives.  That's an expected core httpd "feature" which makes sense for almost all modules, but it is a problem here because mod_ssl_ct's module config needs to also represent the vhost's certificates, which are not reflected in the mod_ssl_ct configuration.  The fix was to create a vhost-specific sconf when reuse of the global configuration is detected.

The submitter's suggested fix would also accommodate the current requirement, but I think it is better for each vhost to have its on config in support of future changes.
Comment 5 Tom Ritter 2016-07-05 11:43:45 UTC
I think this has happened again, but this time on a mixed configuration where some vhosts have SCTs and others don't .  My server config is the same, except I have more CTStaticSCTs lines for more vhosts. They point to empty directories.

The collated.tmp file is written, but it is never copied to 'collated'. When I manually copy it, server works again.