Thunderbird attaches old algorithms in sMIMECapabilities when it sends a signed S/MIME message
Categories
(MailNews Core :: Security: S/MIME, defect)
Tracking
(Not tracked)
People
(Reporter: leszek.zablocki, Unassigned)
References
Details
Steps to reproduce:
- make a self-signed cert (root+user bug#344817#c21), import it
- write an email to yourself
2a. "S/MIME" → ONLY: "Digitally Sign" - "Get Messages"
- "More" → "View Source"
- grab the base64 code under the message
- create a new file "signed.cms" containing the header and footer:
-----BEGIN SIGNED MESSAGE-----
-----END SIGNED MESSAGE-----
- paste the base64 code from the message between the header and footer
- open a program to read the ASN.1 structure, on Widnows, for example, "guiDumpASN-ng"
- check "sMIMECapabilities (1 2 840 113549 1 9 15)"
Actual results:
Thunderbird creates the following structure:
SEQUENCE {
OBJECT IDENTIFIER sMIMECapabilities (1 2 840 113549 1 9 15)
SET {
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER aes256-CBC (2 16 840 1 101 3 4 1 42)
}
SEQUENCE {
OBJECT IDENTIFIER aes128-CBC (2 16 840 1 101 3 4 1 2)
}
SEQUENCE {
OBJECT IDENTIFIER des-EDE3-CBC (1 2 840 113549 3 7)
}
SEQUENCE {
OBJECT IDENTIFIER rc2CBC (1 2 840 113549 3 2)
INTEGER 128
}
SEQUENCE {
OBJECT IDENTIFIER rc2CBC (1 2 840 113549 3 2)
INTEGER 64
}
SEQUENCE {
OBJECT IDENTIFIER desCBC (1 3 14 3 2 7)
}
SEQUENCE {
OBJECT IDENTIFIER rc2CBC (1 2 840 113549 3 2)
INTEGER 40
}
}
}
}
Expected results:
Th. should send ONLY the following OID (in "sMIMECapabilities", signed message): aes256-CBC, aes128-CBC and eventually:
- sha-512 (2 16 840 1 101 3 4 2 3)
- sha-384 (2 16 840 1 101 3 4 2 2)
- sha-256 (2 16 840 1 101 3 4 2 1)
in that order (see bug#1532292), [Outlook2013 adds oid for signature algorithms and it seems to be a good idea.]
|
Reporter | |
Comment 1•1 year ago
|
||
A bug* that can be easily fixed.
*if you want to receive messages encrypted with "rc2CBC" or at least "des-EDE3-CBC".
User-Agent:
Thunderbird 102.11.0 (64-bit), Windows 10
Reproducible: Always
Let's assume the following scenario:
- we use Th. and want to use the best encryption algorithms available
- we send a S/MIME signed ONLY message for an Outlook2013 user who has rc2CBC-64 encryption set to default (this is either an unaware user or a lazy one, whatever). However, its MUA supports "sMIMECapabilities" and creates an encryption profile base for specific certificates/users**. (see bug#135636) Even if the user has the old encryption enabled by default, his MUA will not allow ENCRYPTED messages to be sent with this specific algorithm unless it finds that old algorithm in the last message in the "sMIMECapabilities" extension. Otherwise, it will choose the best/better one from the "sMIMECapabilities" extension.
- Outlook user accepts (trusts) the certificate and sends an ENCRYPTED message to Th. user. Recall that Outlook user has the encryption set to "RC2 (64-bit)".
- Th. user received the encrypted message (after all, his padlock is glowing green). He decides to check what algorithm the message was encrypted with. He creates a file "enveloped.cms" and between the header and footer:
-----BEGIN ENCRYPTED MESSAGE-----
-----END ENCRYPTED MESSAGE-----
pastes base64 source code from received message. "guiDumpASN-ng" ::
OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
SEQUENCE {
OBJECT IDENTIFIER rc2CBC (1 2 840 113549 3 2)
SEQUENCE {
INTEGER 120
OCTET STRING ...
}
}
If Th. had not attached the old algorithms to the "sMIMECapabilities" extension, he would have received a message encrypted with "aes128-CBC" or "aes256-CBC" from Outlook2013 user.
I think every MUA supports AT LEAST "aes128-CBC" and "sha-256", so there will be no interoperability issues. see:
https://luxsci.com/blog/256-bit-aes-encryption-for-ssl-and-tls-maximal-security.html
Authors explore the possibilities of SSL and TLS, but I guess this can also be postponed to S/MIME.
I also think that even if Th. sends only new algorithms in the "sMIMECapabilities" extension, programs that support ONLY old algorithms, will not check the extension "sMIMECapabilities" (send without warning) or will display an error when trying to send a message.
** Proof that Outlook2013 uses the "sMIMECapabilities" extension:
- In Outlook, set the default encryption to "AES 192-bit".
- send an encrypted message to Th. user, who previously sent you a signed message
- Th. user check the encryption with "guiDumpASN-ng":
OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
SEQUENCE {
OBJECT IDENTIFIER aes256-CBC (2 16 840 1 101 3 4 1 42)
OCTET STRING ...
}
Outlook, with encryption set to "AES 192-bit" by default before sending a message to Th. user checked his encryption preferences and found no "aes192-CBC (2 16 840 1 101 3 4 1 22)". Between "aes256-CBC" and "aes128-CBC" (Th. user encryption preferences) chose the better one - "aes256-CBC".
Outlook also sends the old algorithms in the signed message. Here's what the "sMIMECapabilities" extension contains when an Outlook2013 user has the "strongest" algorithms set (AES (256-bit) + SHA512):
SEQUENCE {
OBJECT IDENTIFIER sMIMECapabilities (1 2 840 113549 1 9 15)
SET {
SEQUENCE {
SEQUENCE {
OBJECT IDENTIFIER aes256-CBC (2 16 840 1 101 3 4 1 42)
}
SEQUENCE {
OBJECT IDENTIFIER aes192-CBC (2 16 840 1 101 3 4 1 22)
}
SEQUENCE {
OBJECT IDENTIFIER des-EDE3-CBC (1 2 840 113549 3 7)
}
SEQUENCE {
OBJECT IDENTIFIER aes128-CBC (2 16 840 1 101 3 4 1 2)
}
SEQUENCE {
OBJECT IDENTIFIER rc2CBC (1 2 840 113549 3 2)
INTEGER 128
}
SEQUENCE {
OBJECT IDENTIFIER rc2CBC (1 2 840 113549 3 2)
INTEGER 64
}
SEQUENCE {
OBJECT IDENTIFIER sha-512 (2 16 840 1 101 3 4 2 3)
}
SEQUENCE {
OBJECT IDENTIFIER sha-384 (2 16 840 1 101 3 4 2 2)
}
SEQUENCE {
OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1)
}
SEQUENCE {
OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
}
}
}
}
Links:
guiDumpASN-ng binary for Windows
https://web.archive.org/web/20160828215604/http://geminisecurity.com/wp-content/uploads/tools/GDA-ng-setup.exe
"interoperability" table
https://www.globalsign.com/en/resources/white-paper-smime-compatibility.pdf
Outlook default fallback algorithm
if user wants to enable old encryption, there is such an option - deeply buried in the registry (...Config Editor)
https://learn.microsoft.com/en-us/outlook/troubleshoot/security/error-when-decrypting-message-via-3des-certificate
NSS project page > S/MIME Toolkit (MIME Parser: "one-shot mode")
https://www-archive.mozilla.org/projects/security/pki/nss/smime/
similar: bug#84213, bug#130633, bug#134208, bug#136512, bug#136289, bug#136783#c1, bug#222179, bug#269414, bug#154334
Description
•