Closed Bug 1859978 Opened 8 months ago Closed 8 months ago

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)

Thunderbird 115

Tracking

(thunderbird_esr115+ fixed, thunderbird120 fixed)

RESOLVED FIXED
121 Branch
Tracking Status
thunderbird_esr115 + fixed
thunderbird120 --- fixed

People

(Reporter: nvx2004, Assigned: KaiE)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(3 files, 1 obsolete file)

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:

Component: Message Compose Window → Security: OpenPGP
Keywords: regression
Product: Thunderbird → MailNews Core

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 ?

Flags: needinfo?(nvx2004)

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

Flags: needinfo?(nvx2004)

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

(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?

Flags: needinfo?(nvx2004)

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.

Flags: needinfo?(nvx2004)

Thanks, I can reproduce the bug.

Status: UNCONFIRMED → NEW
Ever confirmed: true

No problem. Feel free to ask should you need further information.

Regressed by: 1679278
Summary: PGP: TB repeatedly asks for subkey password → OpenPGP: If secret subkeys, with unavailable/offline primary key are imported, TB keeps original passphrase protection, and repeatedly prompts for subkey password.

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.

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.

I'd like to offer you a Thunderbird 115.x build with the possible fix for this bug.

Win64:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/RZnXabJYRme6oCJGJgLl2Q/runs/0/artifacts/public/build/target.zip

Linux64:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/JuA5XSkWQ3mdJE-fASYMEg/runs/0/artifacts/public/build/target.tar.bz2

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?

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

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.

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

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.

Assignee: nobody → kaie
Attachment #9360006 - Attachment description: WIP: Bug 1859978 - Test OpenPGP offline private key. → Bug 1859978 - Test OpenPGP offline private key. r=mkmelin
Status: NEW → ASSIGNED
Attachment #9359890 - Attachment description: WIP: Bug 1859978 - Fix passphrase protection if subkeys are imported without a primary secret key. → Bug 1859978 - Fix passphrase protection if subkeys are imported without a primary secret key. r=mkmelin

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.

Attached patch 1859978-test-esr115.patch (obsolete) — Splinter Review
Severity: -- → S2
Priority: -- → P1
Severity: S2 → S3
Blocks: 1852999

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

Status: ASSIGNED → RESOLVED
Closed: 8 months ago
Resolution: --- → FIXED

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.

Attachment #9359890 - Flags: approval-comm-beta?
Attachment #9360006 - Flags: approval-comm-beta?

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

Attachment #9359890 - Flags: approval-comm-beta? → approval-comm-beta+

Comment on attachment 9360006 [details]
Bug 1859978 - Test OpenPGP offline private key. r=mkmelin

[Triage Comment]
Approved for beta

Attachment #9360006 - Flags: approval-comm-beta? → approval-comm-beta+
Target Milestone: --- → 121 Branch
Attachment #9360015 - Attachment is obsolete: true

The fix applies to 115.
The test needs merging, I'll attach a backported patch.

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

Attachment #9359890 - Flags: approval-comm-esr115?
Attachment #9364712 - Flags: approval-comm-esr115?

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

Attachment #9359890 - Flags: approval-comm-esr115? → approval-comm-esr115+

Comment on attachment 9364712 [details] [diff] [review]
1859978-test-backport-115.patch

[Triage Comment]
Approved for esr115

Attachment #9364712 - Flags: approval-comm-esr115? → approval-comm-esr115+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: