Munki doesn't check for revoked server certificate

[GoogleCodeExporter]

After having to revoke and recreate the certificate of my Munki server due to 
the OpenSSL "heartbleed" bug, I noticed that curl does not check certificate 
revocation lists (CRLs) and Munki appears to contain no specific logic to do 
that itself.
curl 7.19.7 and higher support checking against a manually-downloaded CRL, so 
Munki should
1. download the server's certificate (e.g. using openssl s_client -connect 
hostname:443)
2. extract the CRL URL from it (e.g. by piping the certificate into openssl 
x509 -text noout and matching against a regex like "X509v3 CRL Distribution 
Points:\s*URI:(.*?)\s")
3. download that CRL to a file
4. pass it to curl using the --crlfile argument in every curl call
As not all certificates necessarily contain a CRL URL, steps 3 and 4 should be 
skipped if the regex in step 2 does not match.

To also check for revoked root and intermediate certificates, CRL files for the 
entire chain would have to be checked. Unfortunately curl only supports a 
single --crlfile argument, so that is not easily possible.

curl 7.19.7 was released in November 2009. Mac OS X 10.6.8 contains exactly 
that version and all newer versions of OS X contain newer ones, but I am not 
sure whether Apple ever included that version with an update for OS X 10.5, the 
earliest OS X version supported by Munki.

---

What steps will reproduce the problem?
1. Set up a web server with an SSL certificate obtained from a trusted CA or 
import the root certificate into System keychain.
2. Set up Munki with a repository on an SSL-encrypted web server
3. Have the CA revoke the SSL certificate
4. Run sudo managedsoftwareupdate --checkonly

What is the expected output? What do you see instead?
Munki checks for updates like normal. Instead, the update check should fail 
with an invalid (revoked) certificate error.

What version of the Munki tools tools are you using? On what
version of OS X?
Munki 1.0.0.1864, OS X 10.8.5

Original issue reported on code.google.com by michael....@gmail.com on 10 Apr 2014 at 11:42

[GoogleCodeExporter]

I would be happy to review and incorporate a code submission that included 
changes along these lines. I do not plan to work on this any time soon myself, 
primarily as I do not have the time and motivation to set up a proper SSL test 
environment. (I don't use SSL with Munki in my own implementation)

 I do plan to eventually remove the use of curl in Munki and replace it with NSURLConnection and friends.

Original comment by gregnea...@mac.com on 10 Apr 2014 at 1:07

[GoogleCodeExporter]

https://gist.github.com/gregneagle/7571880

Would be interested if this code properly handles revoked certs in your 
testing. It did for me five months ago...

Original comment by gregnea...@mac.com on 10 Apr 2014 at 5:40

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Does not work in my case. Maybe it's because our CA only lists CRL URLs in the 
certificate, no OCSP...
It does look like your code properly handles OCSP, at least with that VeriSign 
test page: on port 443 it presents a valid certificate and on port 2443 it 
presents a revoked one, both of which your code recognizes correctly.
However, I read somewhere that the Apple frameworks only do OCSP for EV 
certificates. So that would be of limited use as well.

I'll see if I can get some example code together which uses curl's --crlfile

Original comment by michael....@gmail.com on 10 Apr 2014 at 6:36

[GoogleCodeExporter]

Once the curl dependency is removed from Munki, I'm not too keen on putting it 
back for this.

And when would you do the revocation check? every single connection to the 
Munki server? (That would be the only "correct" implementation, but at a 
non-trivial cost)

Original comment by gregnea...@mac.com on 10 Apr 2014 at 6:39

[GoogleCodeExporter]

"However, I read somewhere that the Apple frameworks only do OCSP for EV 
certificates. So that would be of limited use as well."

How does Safari behave in your test scenario?

Original comment by gregnea...@mac.com on 10 Apr 2014 at 6:51

[GoogleCodeExporter]

CRLs usually are not updated more often than once a day and they specify a 
validity period of a week or so, so downloading the CRL daily would be 
sufficient.

My certificate is definitely revoked, which I have verified by looking for the 
serial number in the CRL and by using SSL Labs' SSL Server Test.
Safari does not check the CRL either. I actually have yet to find an up-to-date 
web browser that correctly implements revocation checking... Chrome only checks 
its internal list (called "CRLSets") and Firefox only does OCSP (while 
considering the certificate as valid if it is unable to reach the OCSP server 
-- making it useless against man-in-the-middle attacks using the compromised 
private key if the attacker is also able to block access to the OCSP server).

https://developer.apple.com/library/ios/technotes/tn2232/_index.html says that 
you can use SecPolicyCreateRevocation to specifically check for OCSP or CRL 
revocation, but that appears to not be available before OS X 10.9.

The more I read about this certificate revocation stuff, the more I'm thinking 
it's completely broken. Nobody checks CRLs anymore and OCSP is only checked by 
some browsers. OCSP stapling would be a good and scalable solution, but it's 
implemented almost nowhere. Not even all CAs include OCSP URLs in their 
certificates.

Original comment by michael....@gmail.com on 11 Apr 2014 at 7:09