OpenPGP: If secret subkeys, with unavailable/offline primary key are imported, TB keeps original passphrase protection, and repeatedly prompts for subkey password.
Categories
(MailNews Core :: Security: OpenPGP, defect, P1)
Tracking
(thunderbird_esr115+ fixed, thunderbird120 fixed)
People
(Reporter: i.decline082, Assigned: KaiE)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(3 files, 1 obsolete file)
|
48 bytes,
text/x-phabricator-request
|
wsmwk
:
approval-comm-beta+
wsmwk
:
approval-comm-esr115+
|
Details | Review |
|
48 bytes,
text/x-phabricator-request
|
wsmwk
:
approval-comm-beta+
|
Details | Review |
|
9.73 KB,
patch
|
wsmwk
:
approval-comm-esr115+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36
Steps to reproduce:
(1) Set up a new mail account
(2) Import OpenPGP S/E subkeys + a matching public key
(3) A password dialog is shown, the entered password should be used by TB to set a new password for the private subkeys and store it in [ProfD]/encrypted-openpgp-passphrase.txt
(4) Compose a new message, enable OpenPGP signing, and click the Send button.
Actual results:
Some password has been stored in [ProfD]/encrypted-openpgp-passphrase.txt in Step (3) above. However, another password prompt is displayed when sending the message, where the user is required to enter the original OpenPGP S subkey password. I.e., the subkey password has not been changed during the import process.
Expected results:
No password prompt should be shown when sending an OpenPGP-signed message. The subkey password should have been selected randomly during the key import process, stored in [ProfD]/encrypted-openpgp-passphrase.txt, and then used again as needed.
Additional information:
- The problem stared occurring after one of the recent updates.
- Possibly relevant: I have imported into TB only my public key and S/E subkeys, but not the private key itself. I know that https://support.mozilla.org/en-US/kb/openpgp-thunderbird-howto-and-faq#w_what-types-of-openpgp-keys-are-supported states that "Certain keys that are incomplete, for example those using an offline primary key" may not be supported, but I had been using the very same setup before (even with earlier versions of Supernova), and then it was working flawlessly.
- Possibly relevant #2: https://bugzilla.mozilla.org/show_bug.cgi?id=1629195
- Setting up a new TB profile does not lead to any improvement.
Updated•2 years ago
|
| Assignee | ||
Comment 1•2 years ago
|
||
Thanks for your report. To ensure I can properly test your scenario, please answer the following questions.
(In reply to nvx2004 from comment #0)
(2) Import OpenPGP S/E subkeys + a matching public key
Are you using the "Add key" mechanism in account settings? (Which expects to import a secret key)
Or, are you using Thunderbird's OpenPGP Key Manager, file, import secret key from file (which does the same)?
In addition, can you please clarify in more detail what is it that you are importing?
Let me guess, are you importing a specially prepared secret key package (BEGIN PGP PRIVATE KEY BLOCK) which contains:
- for the primary key, only the public key
- a signing subkey, including the private key
- an encryption subkey, including the private key?
Another question, is your preference mail.openpgp.passphrases.enabled set to false (default) or did you explicitly set it to true ?
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Comment 2•2 years ago
|
||
Another question, did you enable a "primary password"?
Are you using the "Add key" mechanism in account settings? (Which expects to import a secret key)
Or, are you using Thunderbird's OpenPGP Key Manager, file, import secret key from file (which does the same)?
In fact, I tried it both ways. Something got broken during one of the recent TB updates and I had to set up TB anew on four different machines (what a pain it is when one cannot just take the profile from one machine and copy it to all the others). I thought that perhaps importing the keys via the Key Manager was the culprit why it did not work the first time. When I saw no improvement after importing via "Add Key", I only used the OpenPGP Key Manager from then on -- it being a faster way to accomplish what I wanted.
In addition, can you please clarify in more detail what is it that you are importing?
Let me guess, are you importing a specially prepared secret key package (BEGIN PGP PRIVATE KEY BLOCK) which contains:
- for the primary key, only the public key
- a signing subkey, including the private key
- an encryption subkey, including the private key?
First I imported a file with my signing and encryption secret subkeys, then another file containing my public key (always in that order). In each case, it was an ASCII-armored key (i.e., not a binary) file. Going about it the other way (again, I had to set up four basically identical profiles...) made no difference.
Both subkeys use the same password.
Earlier TB versions had no problem with the secret key not being imported (both in terms of signing/encrypting and remembering the secret key password).
Another question, is your preference mail.openpgp.passphrases.enabled set to false (default) or did you explicitly set it to true ?
I have never changed this particular preference myself. It is set to false on two machines out of four (I only have access to two of them at the moment), and I guess that the other two machines will show the same thing.
Changing the value to true (and keeping the imported keys as they were) made no difference, so I changed it back to false. Should I try to remove and re-import the keys while this preference is set to true?
Another question, did you enable a "primary password"?
Yes, as per the recommendation listed in the KB (link in the original bug report).
| Assignee | ||
Comment 4•2 years ago
|
||
(In reply to nvx2004 from comment #3)
I have never changed this particular preference myself. It is set to false on two machines out of four (I only have access to two of them at the moment), and I guess that the other two machines will show the same thing.
Changing the value to true (and keeping the imported keys as they were) made no difference, so I changed it back to false. Should I try to remove and re-import the keys while this preference is set to true?
Please do not change any prefs at this point, as it would only further complicate the situation.
I'd like to ensure I properly understand your configuration, so I can use the same.
| Assignee | ||
Comment 5•2 years ago
|
||
(In reply to nvx2004 from comment #3)
First I imported a file with my signing and encryption secret subkeys, then another file containing my public key (always in that order). In each case, it was an ASCII-armored key (i.e., not a binary) file. Going about it the other way (again, I had to set up four basically identical profiles...) made no difference.
Both subkeys use the same password.
Earlier TB versions had no problem with the secret key not being imported (both in terms of signing/encrypting and remembering the secret key password).
What procedure (commands) did you use to create a file that contains your subkeys, only, without the primary key?
What procedure (commands) did you use to create a file that contains your subkeys, only, without the primary key?
In this instance, it was
> gpg --output secret-subkeys.asc --armor --export-secret-subkeys SIGNSUBKEYID! ENCSUBKEYID!
A side note: I vaguely remember that using
> gpg --output secret-subkeys.asc --armor --export-secret-subkeys PRIKEYID
instead results in a slightly different file (should include dummy packets in lieu of the primary secret key); however, I have been using these two commands of exporting secret subkeys more or less interchangeably in the past and never encountered any issues.
| Assignee | ||
Comment 7•2 years ago
|
||
Thanks, I can reproduce the bug.
| Assignee | ||
Updated•2 years ago
|
No problem. Feel free to ask should you need further information.
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Comment 9•2 years ago
|
||
Note, when importing a set of subkeys as you have explained in comment 6, I see that the public key of the primary key is included.
In your steps to reproduce, I think it's unnecessary to perform the separate import of the public key.
| Assignee | ||
Comment 10•2 years ago
|
||
When using TB 115 to import a public primary key together with secret subkeys,
the import code runs into the following bug:
We have code that should remove the existing key protection, and replace it with the automatic protection
(the one that can be protected by the primary password).
If the key material for the primary key is unavailable, it completely skips the re-protection of the subkeys.
This means, the existing protection (as present in the file being imported) is kept.
If the subkeys were previously protected with a passphrase, they are still protected with a passphrase.
If the subkeys were previously unprotected (no passphrase set in the file that is being imported), then the imported subkeys will also be unprotected.
The fix is to always process the subkeys on import, regardless of the availability of the secret key.
This fix, which we should release soon in an Thunderbird update (version yet unknown) will not change the protection of already imported keys. They will remain with the protection (or no protection) that was the result of the incorrect import.
To fix those keys, it will be necessary to enable the separate passphrase feature and use the key details details, passphrase protection tab, to change the protection to the desired state.
Note that this cannot be done yet using the Thunderbird versions that have this bug, it doesn't handle this scenario correctly. A second fix will be included for the key details/properties dialog.
| Assignee | ||
Comment 11•2 years ago
|
||
| Assignee | ||
Comment 12•2 years ago
•
|
||
I'd like to offer you a Thunderbird 115.x build with the possible fix for this bug.
Download, extract, open terminal, cd into the directory where you extracted, then start Thunderbird with parameter -P which will allow you to select and use your existing profile with this test build.
The test build is based on version 115, so it's fine to use it with your profile that you use with stable 115.
Thunderbird will be unable to distinguish whether you have accidentally or deliberately imported a secret key with a separate passphrase. The state of your Thunderbird settings will be treated in the same way as someone having set pref mail.openpgp.passphrases.enabled to true and imported using "keep existing passphrases".
If you simply want to repair the existing profile you already have, and move the imported key under protection of the primary password, do this:
- start thunderbird
- go to config editor
- type/paste the string: mail.openpgp.passphrases.enabled
- set the value to true
- go to openpgp key manager
- find the key you have imported
- double click to view details
- click the tab named "passphrase protection"
- it should tell you that a passphrase is set
- click unlock, and enter the passphrase for the subkey
- after you have unlocked it, a button should appear that offers you to remove the separate passphrase and instead protect it using the primary password (because you have the primary password enabled. For a user who doesn't have a primary password set, the dialog would offer to completely remove the passphrase protection)
- after you have clicked the button, the behavior should be as you expected (which is, after you start thunderbird and enter the primary password, you should not get any prompts for signing and decrypting an email).
- if you don't want to use separate passphrases for openpgp keys, go to config editor again and change mail.openpgp.passphrases.enabled back to value false.
Alternatively you could delete the secret key, and import it again (using the fixed version), and it should also behave as you expected.
Could you please test and let me know if the above explanations are correct, and it indeed fixes the issue for you, after performing these steps?
| Assignee | ||
Comment 13•2 years ago
|
||
FYI, the links to the test builds above belong to this build:
https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=4e5269260938f759712a45c700517cbc09ff0957
| Reporter | ||
Comment 14•2 years ago
|
||
(In reply to Kai Engert (:KaiE:) from comment #9)
Note, when importing a set of subkeys as you have explained in comment 6, I see that the public key of the primary key is included.
In your steps to reproduce, I think it's unnecessary to perform the separate import of the public key.
I see, you are correct. Thanks for the hint!
| Reporter | ||
Comment 15•2 years ago
|
||
Could you please test and let me know if the above explanations are correct, and it indeed fixes the issue for you, after performing these steps?
Thank you! Setting mail.openpgp.passphrases.enabled to true, unlocking the subkeys and protecting them using the primary password, and setting mail.openpgp.passphrases.enabled back to false fixed the issue.
I also tested (on a different machine) the second approach, i.e., deleting and re-importing the keys using the provided build. This fixed the issue as well.
| Assignee | ||
Comment 16•2 years ago
|
||
(In reply to Kai Engert (:KaiE:) from comment #10)
If the subkeys were previously unprotected (no passphrase set in the file that is being imported), then the imported subkeys will also be unprotected.
Luckily, this part of my previous assessment was wrong.
Keys that were unprotected (no passphrase set) in the file being imported, are set to use the automatic passphrase on import - despite this bug.
That means no keys are left unprotected on disk because of this bug.
That means there is no security issue here, in my opinion. At worst, imported subkeys are left protected with the same passphrase that was used to protect the file that was imported.
| Assignee | ||
Comment 17•2 years ago
|
||
| Assignee | ||
Comment 18•2 years ago
|
||
I have attached a separate patch that implements automatic testing for this scenario.
I imports subkeys with private keys, but with the private key for the primary key missing (offline primary key).
When running the new test alone, this bug is demonstrated. The test asks to import without keeping the existing passphrase protection. When attempting to sign the message prompts for the password, which shows the passphrase was not removed.
When applying the attached fix, the new test passes.
Updated•2 years ago
|
Updated•2 years ago
|
| Assignee | ||
Comment 19•2 years ago
|
||
The test patch for comm-esr115 needs to be slightly different (some helper function's aren't async yet).
The actual fix is the same for both c-c and c-esr115.
| Assignee | ||
Comment 20•2 years ago
|
||
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Updated•2 years ago
|
Comment 21•2 years ago
|
||
Pushed by brendan@thunderbird.net:
https://hg.mozilla.org/comm-central/rev/af1da8a012f1
Test OpenPGP offline private key. r=mkmelin
https://hg.mozilla.org/comm-central/rev/2a7db6659c98
Fix passphrase protection if subkeys are imported without a primary secret key. r=mkmelin
| Assignee | ||
Comment 22•2 years ago
|
||
Comment on attachment 9359890 [details]
Bug 1859978 - Fix passphrase protection if subkeys are imported without a primary secret key. r=mkmelin
This is candidate for 115 uplift, so I'd appreciate testing in beta soon.
[Approval Request Comment]
Regression caused by (bug #): 1679278
User impact if declined: Users with advanced GnuPG key get incorrect application behavior (key protected with unexpected passphrase)
Testing completed (on c-c, etc.):
Risk to taking this patch (and alternatives if risky): low. An existing code path is extended to another scenario, which needs it. And a bug in the UI (bool variable test) was fixed that caused incorrect treatment of the keys in the UI.
| Assignee | ||
Updated•2 years ago
|
Comment 23•2 years ago
|
||
Comment on attachment 9359890 [details]
Bug 1859978 - Fix passphrase protection if subkeys are imported without a primary secret key. r=mkmelin
[Triage Comment]
Approved for beta
Comment 24•2 years ago
|
||
Comment on attachment 9360006 [details]
Bug 1859978 - Test OpenPGP offline private key. r=mkmelin
[Triage Comment]
Approved for beta
Updated•2 years ago
|
Updated•2 years ago
|
Comment 25•2 years ago
|
||
| bugherder uplift | ||
Thunderbird 120.0b3:
https://hg.mozilla.org/releases/comm-beta/rev/a28700b89eb8
https://hg.mozilla.org/releases/comm-beta/rev/583532faab81
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Comment 26•2 years ago
|
||
The fix applies to 115.
The test needs merging, I'll attach a backported patch.
| Assignee | ||
Comment 27•2 years ago
|
||
Comment on attachment 9359890 [details]
Bug 1859978 - Fix passphrase protection if subkeys are imported without a primary secret key. r=mkmelin
[Approval Request Comment]
see comment 22
| Assignee | ||
Comment 28•2 years ago
|
||
Comment 29•2 years ago
|
||
Comment on attachment 9359890 [details]
Bug 1859978 - Fix passphrase protection if subkeys are imported without a primary secret key. r=mkmelin
[Triage Comment]
Approved for esr115
Comment 30•2 years ago
|
||
Comment on attachment 9364712 [details] [diff] [review]
1859978-test-backport-115.patch
[Triage Comment]
Approved for esr115
Comment 31•2 years ago
|
||
| bugherder uplift | ||
Description
•