You can clone with
HTTPS or Subversion.
This security fix seems to have caused a regression in checking the certificate of https://www.box.com/
One easy way to see the problem is using DAV's hdav command, which is here built using haskell-tls-extra 0.4.6.1:
joey@gnu:~/tmp/haskell-dav-0.3/dist/build/hdav>./hdav getprops --username=foo --password=foo https://www.box.com/dav/dne
hdav: HandshakeFailed (Error_Protocol ("certificate rejected: certificate is not allowed to sign another certificate",True,CertificateUnknown))
Checking the same url with Chrome, Firefox, and wget, none of them have a problem with its certificate chain. While I can't rule out the possibility that they're all vulnerable to the same hole that was fixed, it seems more lilkely that the fix made to hs-tls was buggy.
Another url that fails is https://www.google.com/
And https://www.github.com/ ....
This only seems to affect the 0.4.6.1 backport. Testing with 0.6.1, it's ok.
Perhaps the backported code depends on a newer version of some other library, such as certificate?
Ouch. That's unfortunate, look like that was a bad idea afterall to backport the security fix. I don't have the resource to support old versions of tls, but i would accept patches. If you really rely on this very old debian version, one easy thing to try is use the tls-retrievecertificate from tls-debug with all the necessary debugging/verbose options, and check manually what's the actual reason of the failure. As you said, the certificate library would play a role here and might need some patching relative to the key usage extension. for example hs-certificate:a156d857189fc880f7d0a2de3310e750994c766b.
Thank for the hint, vincent. I tried backporting certificate:a156d857189fc880f7d0a2de3310e750994c766b onto hs-certificate 1.2.3, which worked easily. I then had to make a minor change to tls-extra-0.4.6.1 to handle the new field.
This seems to have mostly worked; tls-retrievecertificate works as expected for properly signed certificates including www.google.com. And it fails properly for sites with self-signed or snakeoil certificates.
I did find one problem; it doesn't like db.debian.org's certificate:
chain validity : rejected: CertificateRejectOther "certificate is not allowed to sign another certificate"
However, I just checked the current version of tls-, and they *also reject that site. So perhaps that's a separate bug you should look at. (At least Chromium has no trouble with its cert chain.)
thanks. i just reproduced it now, definitely another bug lurking.
certificate without key usage extension are automatically assumed to be
allowed to cert sign and crl sign.