MozillaZine

S/MIME interoperability problem with gpgsm (KMail,Claw Mail)

User Help for Mozilla Thunderbird
mhoeller
 
Posts: 5
Joined: April 20th, 2007, 12:44 pm

Post Posted April 20th, 2007, 12:57 pm

Hello,

I have recieved from 3 different users (all on Thunderbird 1.5.0.10, 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
Michael

tanstaafl
Moderator

User avatar
 
Posts: 38864
Joined: July 30th, 2003, 5:06 pm
Location: Massachusetts

Post Posted April 22nd, 2007, 6:06 am

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.

mhoeller
 
Posts: 5
Joined: April 20th, 2007, 12:44 pm

Post Posted April 22nd, 2007, 12:30 pm

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
Michael

tanstaafl
Moderator

User avatar
 
Posts: 38864
Joined: July 30th, 2003, 5:06 pm
Location: Massachusetts

Post Posted April 23rd, 2007, 8:34 pm

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

Rod Whiteley

User avatar
 
Posts: 11480
Joined: December 6th, 2004, 3:41 am
Location: UK

Post Posted April 24th, 2007, 12:45 am

I've been lurking here, but I don't have anything helpful to say. I wonder of there is anything on this in Bugzilla?
Rod

tanstaafl
Moderator

User avatar
 
Posts: 38864
Joined: July 30th, 2003, 5:06 pm
Location: Massachusetts

Post Posted April 24th, 2007, 2:29 pm

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.

mhoeller
 
Posts: 5
Joined: April 20th, 2007, 12:44 pm

Post Posted April 24th, 2007, 2:57 pm

Hello,

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)

Michael

mhoeller
 
Posts: 5
Joined: April 20th, 2007, 12:44 pm

Post Posted April 24th, 2007, 3:43 pm

Hello,

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
Michael

wurstsemmel
 
Posts: 9
Joined: May 7th, 2006, 4:14 am

Post Posted April 25th, 2007, 6:39 am

Hello,

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,

wurstsemmel
Last edited by wurstsemmel on April 26th, 2007, 2:24 am, edited 1 time in total.

Rod Whiteley

User avatar
 
Posts: 11480
Joined: December 6th, 2004, 3:41 am
Location: UK

Post Posted April 25th, 2007, 10:22 am

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

tanstaafl
Moderator

User avatar
 
Posts: 38864
Joined: July 30th, 2003, 5:06 pm
Location: Massachusetts

Post Posted April 25th, 2007, 12:43 pm

I changed the title and moved the thread from the Thunderbird Bugs forum to the Thunderbird Support forum, per request.

wurstsemmel
 
Posts: 9
Joined: May 7th, 2006, 4:14 am

Post Posted April 26th, 2007, 2:36 am

Special thanks to Rod Whiteley and tanstaafl! The following is posted in the newsgroup. The results will show up in this forum, as well.
Wurstsemmel wrote:Hello,

Mr. Rod Whiteley from the MozillaZine Thunderbird Forums gave me the hint to bring up my questions in this newsgroup.

We experienced, that Tb uses the algorithm RC2 if you send a S/MIME encrypted eMail to KMail. KMail (and Claws Mail) use gpgsm to handle the S/MIME mails. In gpgsm the RC2 algorithm is not implemented for patent reasons.

The behavior of Tb arises from its handling of the S/MIME capabilities. KMail requests an algorithm (I think AES), which Tb does not support. In this case Tb seems to fall back to RC2.

Tb uses 3DES (which it normally does - communicating with other Tb), if you import the certificate manually. As soon as you reply to a KMail eMail by using the "Reply" - button it uses RC2 again.

Are there about:config entries for at least one of the following proposed solutions:

a) Disable RC2 in Tb.
b) Set the default fallback to 3DES.
c) Switch on AES.
d) disable interpreting of "smimecapabilities"

The original thread is at
http://forums.mozillazine.org/viewtopic ... 16#2858116

Interesting readings: http://kb.mozillazine.org/Message_security and http://www.mozilla.org/projects/securit ... ithms.html

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.
**_He thinks, that this is a bug in Tb, which should be fixed._**
The keys mentioned by "patrick at mozilla-enigmail" are set to false (by default).

Thank you very much for your help,

wurstsemmel

mhoeller
 
Posts: 5
Joined: April 20th, 2007, 12:44 pm

Post Posted May 5th, 2007, 2:41 am

Hello,

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!
Michael

wurstsemmel
 
Posts: 9
Joined: May 7th, 2006, 4:14 am

Post Posted May 9th, 2007, 5:57 am

Hi,

this is the response from the newsgroup (mozilla.dev.tech.crypto):
Nick wrote:Great news. Nelson fixed the interoperability problem. There was a
problem in how gpgsm encoded cipher preferences. Thunderbird crypto library
was made more lenient in what it accepted. So, now, TB would correctly
responds to KMail using 3DES instead of RC/40.
See https://bugzilla.mozilla.org/show_bug.cgi?id=379625

Not sure when this fix will make it to a release.

Still unresolved:
* support of AES by Thunderbird
https://bugzilla.mozilla.org/show_bug.cgi?id=379753
* Thunderbird should not support weak crypto
https://bugzilla.mozilla.org/show_bug.cgi?id=84213
* correct generation of SMimeCapabilities by gpgsm
http://www.intevation.de/roundup/aegypten/issue754
* GPGSM does not recognize Verisign certs because of MD2 hash algo
http://www.intevation.de/roundup/aegypten/issue430

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.

mhoeller wrote: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.

This is only valid for SSL.
mhoeller wrote:Neither I have, until now, a mail partner who uses TB 2.0.

I was using Tb 2.0 all the time.

Bye,

wurstsemmel
Mozilla Firefox 2.0.0.3
Mozilla Thunderbird 2.0.0.0
Windows XP Pro SP2

Return to Thunderbird Support


Who is online

Users browsing this forum: Google [Bot] and 5 guests