User Help for Mozilla Thunderbird
14 posts • Page 1 of 1
I have recieved from 3 different users (all on Thunderbird 126.96.36.199, Debian, Mac) encrypted mails which have been created under the use of the out dated an insecure RC2 Algorithm.
I have send these users my CAcert x.509 certificate. Signed mails which I recieve from these users validate but encrypted mails can not be decrypted on my system since I can not read RC2. My system is an openSUSE 10.2, KMail 1.96, gpgsm 1.9.22. Signing and encrypting mails with other MAUs work well with this CAcert certificate.
I have extraxted the encrypted data, removed the base64 part manually and checked the rest with dumpasn1. In all cases I get the result that the mail was encrypted with the RC2 Algorithm.
The question is now, what makes TB "think" to send me an RC2 encrypthed mail?
These error has also been reported in the combination of Claw Mail and TB.
Hope you can help
http://www.mozilla.org/projects/securit ... ithms.html
I don't use S/MIME so I don't know what determines what cipher it uses. I looked in the configuration editor and couldn't find a setting for the key strength, all of the boolean settings for ciphers seemed to be for SSL. RC2 for SSL is disabled by default, you might double check thats still disabled.
Thanks a lot for your answer,
I did more testing the following is interesting and I hope someone can put light into this ...
Here the szenario;
Person A uses Thunderbird
Person B uses KMail
The Problem is that Person B (KMail) can not read encrypted S/MIME Messages from person A (Thunderbird),
the mails are all RC2 encryped, though this is not used from Person B (KMail).
The assumption is that KMail from person B sends with every mail to person A some kind of informtaion
which maks Thunderbird think that it should encrypt with the RC2 algo.
Therefore person A deletes the public cert from B and imports the *.pem manualy again.
Person B did send the cert as PEM to person A,
And... voila Thunderbird from person A uses 3DES.
Person B writes back.
Person A answers and ( it does not work the used Algo is RC2 again ... ?
What is happening here ??
Thanks for any hint
I suggest you send a private message to Rod Whitely asking if he'd post some suggestions. He wrote http://kb.mozillazine.org/Message_security so I suspect has the expertise you need.
http://forums.mozillazine.org/profile.p ... le&u=96365
I haven't had any luck searching the bugzilla database. You could try asking for help in the news://news.mozilla.org/mozilla.dev.tech.crypto newsgroup.
I suggest you read http://www.gossamer-threads.com/lists/g ... ?page=last (dated Apr 18, 2007) http://www.nabble.com/kmail-devel-f6400.xml mentions the same problem with using Thunderbird or Claw mail with Kmail. The definitive statement appears to be in german at http://www.thunderbird-mail.de/forum/vi ... 483#139483 . Running it through Babelfish I get:
I found the following things out:
* TB uses 3DES and RC2/40, sees http://www.mozilla.org/projects/security/pki/nss/smime/ (feature cunning point 11). Thanks at Peter_Lehmann.
* S/MIME (general) uses 3DES, AES or RC2/40 for the symmetrical coding; the transmitter provides a preference list of the algorithms, otherwise we 3DES (?) sees pdf von Jeschke, Seite 17 used
* KMail and/or gpgsm should specify the symmetrical key in the signature on 3DES, possibly happens this not, as determined in this Thread with Eudora.
* The problem steps with gpgsm and _ unites _ (not all?) Thunderbird and Outlook 11 MUAs on (Claws Mail FAQ/S/MIME HowTo)
* the problem step with ms OE and Thawte on (A-netz.de)
* and again: In connection with Thawte certificate and Thunderbird the error also arises. RC2/40 is a weak algorithm. KDE mailing cunning
* gpgsm RC2 does not support (associated nose report)
* sound pdf basic practical course the used algorithm within the range envelopedData under Encryption Algorithm is indicated. EnvelopedData is, as BASE64 mentions further above coded. To decode offers itself www.opinionatedgeek.com. Unfortunately war I it not to select the EnvelopedData of my Mails.
* Would be interesting, which uses coding TB, if one sends oneself a coded Mail. TB should use 3DES, as Peter_Lehmann determined further above. Now one could look at and compare the EnvelopedData of a KMail email. Possibly one comes so also to the preference list mentioned with me as the first point. My assumption is that KMail does not use TB required for 3DES and therefore RC2. Perhaps this could be tested, by not letting TB the certificate add automatically, but the public certificate of the KMail of user in TB directly imports. Possibly doesn't TB use then according to standard 3DES, there it a possibly incorrect signature of KMail knows?? Is it possible that the coding algorithm in the certificate is specified? Could find in addition nix, was only so an idea. I use Thunderbird 2,0 RC1 (localized build de, no LANGUAGE luggage). KMail runs with gpgsm under OpenSuse 10.2. Perhaps we continue to come, if someone can select envelopedData.
That seems like they've switched from their previous position that its completely Thunderbird's fault to its a typical interoperability problem, and that they're considering ways to avoid the interoperability problem by having Kmail provide some additional information.
I interpret that as meaning there is nothing you can do about the problem for the moment, but a future version of KMail might solve the problem. I suggest you file a bug report at https://bugzilla.mozilla.org/ . Being able to reference usenet posting from Kmail/gpgsm developers about your problem should help them take your bug report more seriously.
thanks for the hint. This my thread too. You are correct this thread is going in a little different direction. This was one of the reasons why I started this thread. Meanwhile there are experts on this thread who will help to put some light in the dark.
Yes I think it is a interoperability problem. The interresting question are;
a) why uses TB des to encrypt when the cert is manually imported via pem file, and RC2 when TB imports automated?
b) is this KMail which provides different data or is this the process how TB imports?
As soon as I have futher information I will post it here. Maybe someone has an idea how to test on a) and b)
I think I have to improve my English, my posting seems to be misunder standable. The German thread http://www.thunderbird-mail.de/forum/vi ... 483#139483 was start from me. There we got a little bit stuck. Some very good experts joined recently and we make progress soon. I asked here for help. So this is not crossposting. I was actually refering to the above mentioned thread in German when I wrote "this is my thread" in my previous posting, my applogies for not beeing precise enough. I am very happy about the analysis from tanstaafl.
Being not nativ English spoken I hope I could point out the statement I really wanted to make, And I hope that someone can help me to get answers on the issues a) and b) from the above posting.
Thank you very much
I am one of the guys from the German Tb Forum! I am very sorry for the confusion, for myself I did not know about this second thread in the English forum till Tuesday, 24th of April. I think it was not the best idea to do this kind of cross posting, because a lot of people started testing, despite a lot of work is already done. I just could not answer in time, cause of some urgent exams.
Second, I want to mention, that this subforum is wrong in my opinion. Maybe someone could move the thread to Thunderbird Support. Third, the Subject "Thunderbird uses RC2 Algorithm to encrypt x.509 mails" is misleading and maybe confusing some readers. I would like to change it to "S/MIME interoperability problem with gpgsm (KMail, Claw Mail)"
Tb is NOT using RC2 Algorithm if you send S/MIME encrypted mails to another Tb client or to MS Outlook Express, Outlook I did not test, but I think it is the same. Tb uses 3DES (Triple-DES) if you exchange mails with the mentioned clients (MS Outlook, MS OE). There is no bug in Tb regarding this topic.
I want to kind of summarize:
Tb -> Tb: 3DES
Tb -> MS OE: 3DES
MS OE -> Tb: 3DES
Tb -> KMail: RC2 (auto imported certificate)
Tb -> KMail: 3DES (self (manually) imported certificate)
KMail -> Tb: 3DES
This implies, that KMail submits some information, which algorithm it prefers. MS OE is presenting this information, I think it is called "smimecapabilities".
If you send an eMail from Tb to MS OE, it shows 3DES as the preferred algorithm of the sender (Tb). If you send an eMail from KMail to MS OE, it shows a number, ending with 0.1.101.3.4.1.2. I think this corresponds to AES.
And now we are at the point: KMail requests AES, Tb (and MS OE) are not able to correspond in AES and they make a fallback to RC2, which gpgsm cannot decode.
Some possible solutions are:
a) Disable RC2 in Tb, this might result in compatibilities issues.
b) Set the default fallback to 3DES.
c) Switch on AES.
d) disable interpreting of "smimecapabilities"
But, one could argue, that it is not at all a problem of Tb:
gpgsm/KMail/Claw Mail should set their "smimecapabilities" to a preference list: AES > 3DES > ... or disable the smimecapabilities at all. I think, but this is not proven, that Tb does not use the smimecapabilities.
Some background information: KMail and Claw Mail us gpgsm for the S/MIME part. gpgsm does not support RC2. In http://www.gossamer-threads.com/lists/gnupg/devel/40286 and http://www.gossamer-threads.com/lists/gnupg/devel/40396 "wk at gnupg" stated, that it is not a problem of gpgsm. The keys mentioned by "patrick at mozilla-enigmail" are set to false. Maybe the implementation of gpgsm in KMail/Claw Mail is the problem.
Maybe someone in the forum knows, if there are about:config entries for the above mentioned solutions a) to c). One could think about setting one of the solutions to default in the next security update / major release. Lets say enable AES. But this is not my part to decide...
Please do not hesitate to contact me by PM or write a post, if you have problems understanding my english.
If you think it would be a good idea to stop here and discuss this in the Newsgroup, please give me a feedback.
Greetings from Germany,
Last edited by wurstsemmel on April 26th, 2007, 2:24 am, edited 1 time in total.
I think your summary is good. I suggest you post it in news://news.mozilla.org:119/mozilla.dev.tech.crypto to reach people who might know how Thunderbird handles the S/MIME Capabilities extension.
I changed the title and moved the thread from the Thunderbird Bugs forum to the Thunderbird Support forum, per request.
Special thanks to Rod Whiteley and tanstaafl! The following is posted in the newsgroup. The results will show up in this forum, as well.
are there new findings? I have read that the support for RC2 is disabled for TB 2.0 by default. I could not figgure out if this is only valid for ssl or also for smime. Neither I have, until now, a mail partner who uses TB 2.0.
Thanks a lot for all the work, already done!
this is the response from the newsgroup (mozilla.dev.tech.crypto):
I want to thank all the guys from the newsgroup, they made a great job!!
Maybe the topic should be moved back to the "Thunderbird Bugs" subforum.
This is only valid for SSL.
I was using Tb 2.0 all the time.
Mozilla Firefox 188.8.131.52
Mozilla Thunderbird 184.108.40.206
Windows XP Pro SP2
14 posts • Page 1 of 1
Who is online
Users browsing this forum: Bing [Bot] and 2 guests