Bug #373
when certificate checking is on in the config, connection to jabber.ccc.de doesn't work
Status: | Closed | Start date: | 11/03/2012 | |
---|---|---|---|---|
Priority: | High | Due date: | ||
Assignee: | - | % Done: | 0% | |
Category: | - | |||
Target version: | v11 - January Judo | |||
Component: |
Description
when attempting to connect, I get a message box saying
"Certificate info
cert uses weak crypto:
md5withrsa:
[some stuff], CN=CA Cert Signing Authority
[some more stuff]"
there is no "OK" or "accept" button in this box. the only way to get rid of it is to hit the "back" button. Gibberbots connection attempt then times out. Installing the CA Cert root certificate and classe 3 certificate into the phone makes no difference to this behaviour.
Workaround: disable certificate checking. Which sucks.
Associated revisions
Merge pull request #373 from n8fr8/bugs_fixes_from_13.0.7
Bugs fixes from 13.0.7
History
#1 Updated by n8fr8 about 5 years ago
- Status changed from New to In Progress
- Target version set to v11 - January Judo
In our next update, we are adding support for user acceptance/override of our built-in cert verification. This would allow for the ok/accept feature you want.
In addition, we are looking into the issue of someone like the CCC using an MD5-based certificate which has been known to be not a strong hash to use for quite a while.
Here is a note from 2008 about MD5-based certs:
http://securology.blogspot.in/2008/12/forging-rsa-md5-ssl-certs.html
#2 Updated by mhellwig about 5 years ago
OK, so just to make sure I understand, that message box I'm getting is NOT the generic one knows from everywhere, i.e. "certificate not signed by a trusted authority" (or something like that), which should have been cleared up by installing the cacert root and class 3 certificate but rather a complaint about the kind of certificate that is being used?
Note that the jabber.ccc.de admin tells me that his own certificate does not use md5, it's sha1. I presume the complaint then is about the cacert root certificate?
#3 Updated by n8fr8 about 5 years ago
mhellwig wrote:
OK, so just to make sure I understand, that message box I'm getting is NOT the generic one knows from everywhere, i.e. "certificate not signed by a trusted authority" (or something like that), which should have been cleared up by installing the cacert root and class 3 certificate but rather a complaint about the kind of certificate that is being used?
Gibberbot actual contains its own custom certificate store based on Debian's that includes CACert Root.
Yes, the error is that either the end certificate, or one in the chain, uses MD5.
Note that the jabber.ccc.de admin tells me that his own certificate does not use md5, it's sha1. I presume the complaint >then is about the cacert root certificate?
Hmm. I will do some more debugging on this tonight. If the CACert Root itself is using MD5, but we have that in our local cert store for validation, then we can trust it, since there is no chance of an MD5 collision attack in that case.
Thanks for the follow-up. Will get back to you shortly.
#4 Updated by n8fr8 about 5 years ago
Can you test with Jabber.org and the version of Gibberbot you have?
The interesting thing is that Jabber.org also uses CACert, but we don't see the "weak" warning with Jabber.org.
#5 Updated by n8fr8 about 5 years ago
Actually ignore that... Jabber.org uses StartCom.
#6 Updated by mhellwig about 5 years ago
ignores dutifully
#7 Updated by n8fr8 about 5 years ago
The solution seems to be that we should add the CACert intermediate certificate into our local cert store, not just the root, as discussed in this thread here:
http://bugs.bitlbee.org/bitlbee/ticket/935
In addition, we should then not check for weak/MD5 certs if they are stored in our local store, since the MD5 collision attack doesn't work on a locally stored cert.
Working on this now, and will push a new Gibberbot out once we've validate the solution.
#8 Updated by n8fr8 about 5 years ago
Fixed!
See log here of successful verification of jabber.ccc.de
http://pastebin.ca/2248753
#9 Updated by n8fr8 about 5 years ago
- Status changed from In Progress to Resolved
#10 Updated by n8fr8 almost 5 years ago
- Status changed from Resolved to Closed