Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

regression from security fix in 15885c0649ceabd2f4d2913df8ac6dc63d6b3b37 #32

Closed
joeyh opened this Issue · 5 comments

2 participants

@joeyh

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.

@joeyh

Another url that fails is https://www.google.com/
And https://www.github.com/ ....

@joeyh

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?

@vincenthz
Owner

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.

@joeyh

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.)

@vincenthz
Owner

thanks. i just reproduced it now, definitely another bug lurking.

@vincenthz vincenthz closed this issue from a commit
@vincenthz certificate without key usage extension are automatically assumed to be
allowed to cert sign and crl sign.

fix #32.
fd7caae
@vincenthz vincenthz closed this in fd7caae
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.