Must allow de-selecting S/MIME signing (and possibly don't automatically enable it) if no S/MIME signing key is configured.
Categories
(MailNews Core :: Security: S/MIME, defect)
Tracking
(Not tracked)
People
(Reporter: it, Unassigned)
References
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Steps to reproduce:
Use an email account where S/MIME credentials are configured for encryption, but not for signature.
Start composing a message, select encryption.
Actual results:
Digital signature is automatically selected as well.
Which is strange in itself, when the user just selected encryption.
It is even pretty silly in case there is no signature key configured:
The user cannot deselect the use of a signature, and so the email cannot be saved or sent in (just) encrypted form.
Expected results:
Signature should not be selected automatically when encryption is requested,
and in case no signature key is available, signature must not be auto-selected.
|
||
Comment 1•4 years ago
|
||
Signing is essential to have security, thus we enable it by default.
I don't think we want to support odd cases of not being able to sign.
|
||
Comment 2•4 years ago
|
||
We automatically enable signing, because it is useful to get additional security.
We don't enforce signing. After you have enabled encryption, it is possible to disable signing manually.
I just tested it. Using TB 91.x I was able to send an S/MIME message with encryption, without signature.
Given the fact that we allow configuring S/MIME certificates separately for encryption and signing, I can agree that we could be smarter here, and not enable signing automatically if no S/MIME signing certificate is configured.
|
|
||
Comment 3•4 years ago
|
||
(In reply to David von Oheimb from comment #0)
Expected results:
Signature should not be selected automatically when encryption is requested,
Disagree. If a secret key is available, it makes sense to sign, too. Encryption with the ability to verify the sender is good.
and in case no signature key is available, signature must not be auto-selected.
I think we should investigate if this can be changed.
In theory, if no S/MIME signing certificate is configured, and if the S/MIME technology is activated, we could refrain from automatically enabling signing.
However, it would require careful tweaking of our logic. What if the user starts with OpenPGP technology, enables encryption (with auto-enable signing), then switch tech to S/MIME?
I think we should never automatically downgrade security switches (only upgrade).
For the time being, it is possible to manually disable signing, if desired or impossible.
|
|
||
Updated•4 years ago
|
|
Reporter | |
Comment 4•4 years ago
|
||
Signing is essential to have security, thus we enable it by default.
"security" is a very fuzzy word.
Those who have some understanding of the topic know that confidentiality (typically achieved by encryption)
is fundamentally different from authenticity&integrity (typically achieved by digital signature).
I don't think we want to support odd cases of not being able to sign.
With public-key crypto, which is asymmetric, it is absolutely not odd to do just encryption without signing.
Asymmetric encryption does not require credentials at the sender side, but just knowledge of a public key per recipient.
So email senders MUST be able to do "just" encryption in case they do not have a key pair themselves.
:mkmelin, you should read and reason more carefully.
As I wrote above, the situation described in this bug report is that the sender did not set up a signature key (likely because he/she does not have one).
Still the user should be able to send encrypted emails, but TB prevents this by insisting to do in addition a signature, which is impossible without the private key.
So this clearly is a bug, and its was wrong that you closed this as WONTFIX.
|
|
Reporter | |
Comment 5•4 years ago
|
||
(In reply to Kai Engert (:KaiE:) from comment #2)
We automatically enable signing, because it is useful to get additional security.
As far as that I can agree.
We don't enforce signing. After you have enabled encryption, it is possible to disable signing manually.
No, and this is the specific point of this bug:
TB prevents saving and sending encrypted mails in case no signature key is set up because in this case the user cannot disable message signature, and attempting the signature of course fails in this scenario.
I just tested it. Using TB 91.x I was able to send an S/MIME message with encryption, without signature.
I am pretty sure that in your test did not remove the ability to sign, which contradicts the scenario given.
It would have been good if also you had read the bug report more carefully before your first answer,
but from your second response it turns out that you did in between.
As explained, this issue is not just a missing feature, but an actual bug.
I'll re-add the respective
Given the fact that we allow configuring S/MIME certificates separately for encryption and signing, I can agree that we could be smarter here, and not enable signing automatically if no S/MIME signing certificate is configured.
Good to hear. This part surely is "just" an enhancement.
I think we should investigate if this can be changed.
In theory, if no S/MIME signing certificate is configured, and if the S/MIME technology is activated, we could refrain from automatically enabling signing.
Yes.
However, it would require careful tweaking of our logic. What if the user starts with OpenPGP technology, enables encryption (with auto-enable signing), then switch tech to S/MIME?
I think we should never automatically downgrade security switches (only upgrade).
It should be fine to automatically downgrade in case this reverts an automatic upgrade.
Yet it would be simpler (and IMHO more clean) to not to automatically upgrade.
A third way out could be to keep the automatic upgrade and ignore it in case it is not possible,
but this is somewhat dangerous.
For the time being, it is possible to manually disable signing, if desired or impossible
This would be a fourth - and likely the best - option, but it is the point of this bug that
this is not possible because the TB UI simply does not allow deselecting the "Digitally Sign This Message"
in case no private key is available. This behavior is nonsensical.
|
|
Reporter | |
Comment 6•4 years ago
|
||
Argh, Bugzilla send out my response prematurely.
To finish up the "I'll re-add the respective" in the middle of the above text:
I've re-added the "defect" label and corrected the changes you did to the bug title.
|
|
||
Comment 7•4 years ago
|
||
(In reply to David von Oheimb from comment #4)
:mkmelin, you should read and reason more carefully.
Still the user should be able to send encrypted emails, but TB prevents this by insisting to do in addition a signature, which is impossible without the private key.
You could also build cars without breaks, and drive around. There are good reasons not to build such cars.
|
|
Reporter | |
Comment 8•4 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #7)
(In reply to David von Oheimb from comment #4)
:mkmelin, you should read and reason more carefully.
Still the user should be able to send encrypted emails, but TB prevents this by insisting to do in addition a signature, which is impossible without the private key.You could also build cars without breaks, and drive around. There are good reasons not to build such cars.
This new remark makes little sense, even with goodwill, reading "breaks" as "brakes".
Do you understand that it is impossible to do a signature when no private key is given?
And that TB - to stay in the picture you brought up - refuses to activate the car brakes
as long as the driver does not present his license?
|
|
||
Comment 9•4 years ago
|
||
Understand, but that's a false analogy as signature has little to do with identity really.
People like to confuse that signature has the same meaning with plain message as it has when the message is encrypted. While it does has those same properties as well, they are really just an extra. With encryption only the whole communication may easily be compromised - you need a signature to know it's a confidential connection.
|
|
Reporter | |
Comment 10•4 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #9)
Understand, but that's a false analogy as signature has little to do with identity really.
Are you kidding?
Otherwise I must conclude from your responses that you simply have too little understanding for discussing IT security/cryptography topics.
What makes things worse is that you seem to presume for yourself to have sufficient knowledge to be able to make strong statements here.
No, your analogy was false. Not signing a message is by far not as bad as building/driving a car without brakes.
Your story proves wrong already by the simple fact that most people do not care to encrypt, let alone sign emails,
while everyone will agree that a car without brakes is a no-go.
And signing an email has an entirely different purpose than encrypting it (and has quite different prerequisites).
For those users that do care about email security, including myself,
confidentiality (which is achieved by encryption and requires authenticity of the public key of each recipient),
is typically much more important than integrity of the message contents and authenticity of the sender
(which is achieved by signature and requires an authentic public key of the sender, typically achieved by
a certificate connecting the sender's identity and public key, signed directly or indirectly by a trusted party).
People like to confuse that signature has the same meaning with plain message as it has when the message is encrypted. While it does has those same properties as well, they are really just an extra. With encryption only the whole communication may easily be compromised - you need a signature to know it's a confidential connection.
No, no, no! You are fundamentally confusing concepts yourself.
- With (proper) encryption only, you get confidentiality, but neither integrity nor authenticity of the message.
For asymmetric encryption the prerequisite is, as I wrote above, (a typically signed statement for) the authenticity of the public key of the recipient. - With (proper) signing only, you get integrity and authenticity of the message, but no confidentiality.
For digital signing the prerequisite is, as I wrote above, (a typically signed statement for) the authenticity of the public key of the sender.
These two types of protection/security are orthogonal (i.e., unrelated to each other).
To conclude, it does make perfect sense to do encryption only. Whether this is sufficient depends on the use case.
All you need for this is an authentic public key of the recipient.
So for confidentiality, by no means do you need credentials of the sender.
It is conceptually wrong for Thunderbird to connect this with email signing, and
much worse, it is a show stopper for encryption to insist, like TB currently does,
that the sender provides credentials suitable for signing.
|
|
||
Comment 11•4 years ago
|
||
With (proper) encryption only, you get confidentiality,
The conversation is not confidential if encrypt-only. In a confidential conversation both parties must be able to trust that nobody else heard what was said. You don't get any guarantees for that with encrypted only.
|
|
Reporter | |
Comment 12•4 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #11)
With (proper) encryption only, you get confidentiality,
The conversation is not confidential if encrypt-only. In a confidential conversation both parties must be able to trust that nobody else heard what was said. You don't get any guarantees for that with encrypted only.
Now I understand better what you are aiming at.
It depends on the exact notion of confidentiality, the perspective, and pragmatic evidence.
- Seen by sender, doing the encryption only is certainly sufficient because he knows himself as the originator of the message (while of course he must trust the receiver (s) not to leak the contents).
- Without sender authenticity in theory the recipient does not know with whom he shares the encrypted information. So I agree that formally it would be much better to be assured also of the actual origin of the message by verifying a signature (while of course in addition the recipient must trust the sender not to leak the contents by other means).
Yet in practice for the confidentiality of the overall conversation only the encryption is essential because confidentiality gets compromised very easily, while an encrypted email typically contains sufficient "private" detail such that in combination with the metadata (including timing aspects) a human receiver can judge its authenticity and thus also can be sure who is the other party the information is shared with.
BTW, once the authenticity of the original sender on a conversation is clear (regardless by which means it has been established), this typically carries over to subsequent messages because their responder usually refers to contents (e.g., by quoting them) that he can only have learned by successful decryption of the message he just received, which indirectly authenticates him as the source of the next message.
Here is much better analogy than your one involving car brakes:
Encryption is like sending a "real" (physical) letter to the mailbox at the house of the recipient where only he can open and read it.
Most often such a letter is not is not (physically) signed, and it is extremely rare that it is (physically) sealed for protecting authenticity and integrity.
When receiving such a simple letter from a friend, would you refuse to see its contents as confidential just because it was not signed and sealed?
|
|
||
Comment 13•4 years ago
|
||
(In reply to David von Oheimb from comment #12)
Yet in practice for the confidentiality of the overall conversation only the encryption is essential because confidentiality gets compromised very easily, while an encrypted email typically contains sufficient "private" detail such that in combination with the metadata (including timing aspects) a human receiver can judge its authenticity and thus also can be sure who is the other party the information is shared with.
Sorry, but this is clearly wrong - and exactly why I'm saying people don't understand how important signatures are. "Trust" is not about the person, nor the content. You don't get any confidentiality by judging the authenticity of the content.
BTW, once the authenticity of the original sender on a conversation is clear (regardless by which means it has been established), this typically carries over to subsequent messages because their responder usually refers to contents (e.g., by quoting them) that he can only have learned by successful decryption of the message he just received, which indirectly authenticates him as the source of the next message.
Exactly, that's why it's important to have confidentiality to begin with.
Encryption is like sending a "real" (physical) letter to the mailbox at the house of the recipient where only he can open and read it.
Most often such a letter is not is not (physically) signed, and it is extremely rare that it is (physically) sealed for protecting authenticity and integrity.
Eh, most letters are sealed closed, no?
When receiving such a simple letter from a friend, would you refuse to see its contents as confidential just because it was not signed and sealed?
If I received an unsealed letter, I would not expect the letter to have any confidentiality left no.
If my granma sent me 1000€ in an envelope and not sealed it, maybe the mailman happened to peak, and switch it to 10€... The note "Merry Christmas, here is some cash" would still apply, and judging from the content/sender, nothing was wrong.
If she sealed the envelope I might notice it had been steamed opened and get suspicious...
|
|
Reporter | |
Comment 14•4 years ago
|
||
(In reply to Magnus Melin [:mkmelin] from comment #13)
(In reply to David von Oheimb from comment #12)
Yet in practice for the confidentiality of the overall conversation only the encryption is essential because confidentiality gets compromised very easily, while an encrypted email typically contains sufficient "private" detail such that in combination with the metadata (including timing aspects) a human receiver can judge its authenticity and thus also can be sure who is the other party the information is shared with.
Sorry, but this is clearly wrong - and exactly why I'm saying people don't understand how important signatures are. "Trust" is not about the person, nor the content. You don't get any confidentiality by judging the authenticity of the content.
No, this was not wrong. Did you read carefully?
1 . The only aspect for which I mentioned the term "trust" is where one actually needs trust in order to get (or better: maintain) confidentiality. Namely, even if the to-be-private information is transmitted in the best protected way (including unbreakable encryption and signature),
this does not help much in case any of the parties involved in the conversation leaks this information elsewhere! In most cases there is no way to enforce that this does not happen, and therefore, all the parties involved must trust each other not to leak it.
2. I had agreed that in principle, authenticity of the message source is essential for the receiver because otherwise it is unclear with whom he shares the information transmitted. Yet as explained, this authenticity can - and typically is to a pragmatically sufficient degree - established by other means.
BTW, once the authenticity of the original sender on a conversation is clear (regardless by which means it has been established), this typically carries over to subsequent messages because their responder usually refers to contents (e.g., by quoting them) that he can only have learned by successful decryption of the message he just received, which indirectly authenticates him as the source of the next message.
Exactly, that's why it's important to have confidentiality to begin with.
Right, but having confidentiality to begin with was not questioned here.
Encryption is like sending a "real" (physical) letter to the mailbox at the house of the recipient where only he can open and read it.
Most often such a letter is not is not (physically) signed, and it is extremely rare that it is (physically) sealed for protecting authenticity and integrity.Eh, most letters are sealed closed, no?
Of course I did not mean "sealed" in the sense of pasting up a letter, as usually done.
Instead, I meant "sealed" in the old-fashioned physical way of adding a wax emblem or the like, see, e.g, https://en.wikipedia.org/wiki/Seal_(emblem), which to some extent makes the letter tamper-proof and authentic.
When receiving such a simple letter from a friend, would you refuse to see its contents as confidential just because it was not signed and sealed?
If I received an unsealed letter, I would not expect the letter to have any confidentiality left no.
With the given clarification of the word "sealed" in mind, again my question:
Would you honestly doubt the confidentiality of a (regularly closed) letter just because it does not include a written signature
(and does not have a old-fashined seal attached to it that could have been used to prevent tampering with its contents)?
If my granma sent me 1000€ in an envelope and not sealed it, maybe the mailman happened to peak, and switch it to 10€... The note "Merry Christmas, here is some cash" would still apply, and judging from the content/sender, nothing was wrong.
If she sealed the envelope I might notice it had been steamed opened and get suspicious...
Your new example has on relevance here because it aims at integrity,
but what we are discussing is how important (or not) it is for the confidentiality of a message that the message is explicitly signed.
Again, my statement is that in many cases the contents of an encrypted message in conjunction with meta information provide practically enough evidence for a human receiver to judge the authenticity of the message source, even if it is not digitally signed (or if a signature has been provided but he was unable to verify it), and thus he typically has sufficient guarantees for considering the contents confidential between himself and the (alleged) sender of the message.
|
|
Reporter | |
Comment 15•4 years ago
|
||
Again, insisting in digitally signing a message when no S/MIME signature credentials are configured
when sending an S/MIME encrypted message makes no sense.
Description
•