Open Bug 1438949 Opened 7 years ago Updated 2 years ago

S/MIME Certificate Replacement Attacks

Categories

(MailNews Core :: Security: S/MIME, defect)

Product:
MailNews Core
Component:
Security: S/MIME
Type:
defect

Tracking

(Not tracked)

People

(Reporter: jens.a.mueller, Unassigned)

Details

(Keywords: sec-want)

User Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Firefox/52.0 Build ID: 20170929010941 Steps to reproduce: In the scope of academic research within the efail project, in cooperation with Ruhr-University Bochum and FH Münster, Germany we discovered a security issue in Thunderbird's handling of certificates which allows an attacker to completely replace the keys used for S/MIME encrypted communication. ************************************** S/MIME Certificate Replacement Attacks ************************************** Affected product: Thunderbird (52.5.2) /Attacker model/: Our attacker model is an active attacker who already has access to the victim's S/MIME encrypted emails because either she sits on the wire, she hacked the victim's IMAP account or maybe she even runs the mailserver. Yet she obviously cannot not decrypt the S/MIME end-to-end encrypted communication. This is a strong attacker model, but exactly what S/MIME is meant to protect from. /Goal of the attack/: Let's assume two communication partners -- Alice and Bob -- have already set up S/MIME encrypted communication to securely interchange sensitive emails. The attacker's goal is to change the keys used for encryption. /Attack description/: For enhanced usability, Thunderbird offers the ability to automatically (and without the user noticing) install certificates contained in S/MIME signed emails. At first glance this should not be a security concern as long as only valid certificates signed by a trusted certificate authority are imported. However, various companies (trusted CAs) offer the service of issuing free S/MIME certificates for a certain email address to anyone who can proof to open a link contained in a confirmation mail. This is completely in the scope of our attacker model: The attacker can apply for a certificate for the victim's email address, read his emails and click the confirmation link. This way, the attacker manages to gain a valid and trusted S/MIME certificate, e.g. for the user Bob. She is now able to replace the certificate linked to the user Bob simply by sending an email containing the new certificate to Alice. Further emails from Alice to Bob will be encrypted with the attackers public key. An active MitM attacker now can decrypt these messages, re-encrypt them with Bob's original public key and forward to the Bob. Also weaker attackers like someone who guessed the password for Bob's IMAP account are able to replace the emails. The security of S/MIME encrypted communication is reduced to anyone can read and manipulate a user's emails somewhere within the process of delivery. /Proof of concept/: We first sent an email signed by our university's certificate authority (trusted) and tested if Thunderbird would automatically import the entity's certificate (class 2 -- organization validated) and therefore be able to send encrypted emails to this entity. Secondly, we obtained a free S/MIME certificate (class 1 -- email/domain validated) from a different trusted CA (Comodo, WiseKey, etc.) for this entity and reproduced the steps above. Actual results: Thunderbird silently imported the new certificate without any user interaction required and uses it for any further encrypted communication with the entity. Digital signatures do not help because the attacker can simply decrypt, strip the signature and re-sign the mail using her own secret key. It must be noted that the attack can be easily detected if the user manually checks the certificate details and spots another CA issuer than usual. However, it can be assumed that only few users perform such checks every time before sending encrypted mail. We think that this attack is quite realistic because -- in comparison to most attacks on cryptographic key exchange -- the attacker is not bound a certain key for decrypting and re-encrypting. She can send the original certificate of Bob to Alice, the public keys are restored and the attacker is out of the loop without anyone noticing. Expected results: /Mitigation/: Before importing and replacing new S/MIME certificates, the user should be asked at least once (at least if the certificate is issued by a different CA or has a different trust level). Another option would be to auto-import silently but ask the user which certificate to choose for encryption if multiple certificates for the same email address had been imported.
Ben: can you take a stab at rating this and finding an appropriate owner?
Flags: needinfo?(ben.bucksch)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(ben.bucksch)
Hey Dan, sorry, but I don't read bugmail, including needinfos. So, I never saw your question, sorry. > various companies (trusted CAs) offer the service of issuing free S/MIME certificates for a certain email address to > anyone who can proof to open a link contained in a confirmation mail. This is completely in the scope of our > attacker model: The attacker can apply for a certificate for the victim's email address, read his emails and > click the confirmation link. Right. That goes to the core of SSL and S/MIME trust model: You rely on the CAs. And the CAs unfortunately rely on insecure measures to verify you. Which undermines the whole trust model. We can't really "pin" a certificate for a user either, nor even ping the CA for that user, because the SSL/S/MIME model has expiry and re-issue built into the very model, and the user can change CAs at any time. It's the CA's role to ensure that only the owner of the email address gets a cert, but they fail here. So, yes, it's valid, but it's inherent in S/MIME. PGP doesn't have that issue, because the user needs to manually confirm the validity of every cert. Unless it's signed by another trusted cert, which allows you to renew certs without the trust breaking. S/MIME can't do that.
I'm going to unhide this, because a) efail has been widely published in the media and the paper <https://efail.de> is out, too. b) the attack here is pretty obvious to anybody who has ever obtained a free S/MIME cert and who has a security mind that works c) we need ideas how to fix this
Group: mail-core-security
One obvious way would be to require CAs to more carefully verify the applicant of a new S/MIME certificate. How, what exactly to require, that's another question...
Passport? Like when you get a bank account. The banks are required to verify your identity, by passport or government-issued ID card.
Keywords: sec-want
Side note: we have not covered these issues in the efail paper (but we reported this `it's-by-design-but-i-kinda-feel-uncomfortable' issue to all affected vendors in February so I guess it's okay for this bug to be public). In the end it's a usability-security trade-off in S/MIME.
Component: Security → Security: S/MIME
Product: Thunderbird → MailNews Core
Version: 52 Branch → 52

Any updates on this issue? Was the auto-cert-overwrite behavior changed for Thunderbird?

It's still the same AFAIK. Would be inclined to wontfix this. Asking could do more damage than it could do help the situation. It's a broken trust model, and having the user second guess if the CA did the right thing... how could they even begin to assess that?

The security of S/MIME encrypted communication is reduced to anyone can read and manipulate a user's emails somewhere within the process of delivery.

It's true and it's serious.

The attack here is valid and completely destroys the promise of S/MIME.

There are 2 possible solutions:

  • Change all CAs to stop issuing email certificates based on email confirmation. However, letsencrypt uses a similar model for HTTPS certs. So, CA policies are very unlikely to change.
  • Thunderbird insist on certificate continuity. That means, before a new certificate is imported, and if we already have a cert for that email partner, the user needs to manually approve and explicitly confirm the new certificate. This is just a confirmation dialog, but makes it impossible for an attacker to silently replace the key, as described above. This is the same mechanism used by other systems, like Signal and various others.

Since certificates have to be changed/renewed yearly and that is a normal thing, having to confirm every update would destroy usability. In the end you'd be none the wiser as to whether it's a real or fake update.

How about warning only if the CA changes?
Also when the validity period is far from over? (Which would limit the time frame of an attack seriously.)

My three cents:

  • There will always be CAs that issue S/MIME certificates based on the ability to receive an email address (actually, most commercial S/MIME CAs, even those you pay for, use this way of "authentication" / certificate deployment).
  • As Magnus pointed out, certificates change after one (or depending on your CA, at least after three) years. However, IMAPS/POP3S/SMTPS server certificates also change regularly -- and TB also shows a warning here for new certificates, for good reasons.
  • That said, warning only if the CA changes maybe a good trade-off. Without having any numbers, my guess is that most organisations which actually use S/MIME do use their institutional CA and security-aware users will get suspicious if it changes to $SomeFreeCA).

(In reply to Ben Bucksch (:BenB) from comment #11)

How about warning only if the CA changes?
Also when the validity period is far from over? (Which would limit the time frame of an attack seriously.)

I guess at least the time frame would be doable. For personal S/MIME certs, it's easy you switch. OTOH who are we kidding - personal S/MIME are as dead as they could be, especially after <keygen> was discontinued.

(In reply to Jens Müller from comment #12)

However, IMAPS/POP3S/SMTPS server certificates also change regularly -- and TB also shows a warning here for new certificates, for good reasons.

Those usually have proper certificates, and there is no warning if it changes (and the CA is trusted).

personal S/MIME are as dead

Yes, but corporate S/MIME is still alive. As Jens said, this is the typical scenario for S/MIME, and they use a single CA for the entire company. So, the warning when switching CAs makes sense.

(In reply to Jens Müller from comment #12)

  • As Magnus pointed out, certificates change after one (or depending on your CA, at least after three) years. However, IMAPS/POP3S/SMTPS server certificates also change regularly -- and TB also shows a warning here for new certificates, for good reasons.

Where does TB show such a warning? I don't think I've never seen a warning if a server changes from one good cert to another good cert. Are you referring to a different scenario?

I think that's only showed when connecting to servers where you'd have to add exceptions [I think broken on trunk].

For corporate S/MIME, the whole situation isn't really an issue. They would be the ones administrating the mail server and potentially also giving the certificates, probably administrating your machine. They might as well just hand out a "real" one as fake. It's all under their control. For corporation usage, you also don't really have to care about free speech and such aspects either. If the certificate is from outside the organization - you have the same situation as for personal S/MIME certificates, that there's no knowing if the other party changed CA.

You're making a lot of assumptions there. If Amnesty International were using S/MIME with a corporate CA, then most or all of your assumptions (secure network, managed machine, low risk) would fall and the user would be vulnerable, possibly facing death.

I'm talking about the corporate internal traffic between sites. If it's outside the organization, you get the personal S/MIME case no? How would the outside user know if Amnesty really switched CA for some of their certificates or not.

Where does TB show such a warning?

[off-topic] Sorry, my fault. I though this would be the case because I got a warning message once when my institution updated to a new IMAPS cert, but they may have done something dumb back then (e.g., expired, self-signed, etc.).

In any case, I think that while S/MIME is rarely used in practice, for organizations who actually rely and depend on its end-to-end security promises, it should not be possible to basically "overwrite" public keys (even though I do definitely see the benefits of auto-import for user experience).

The security model of S/MIME and TLS relies on the hope that nobody will create false certificates, intentionally or unintentionally.

This bug report is a complaint that "hope" isn't secure, because CAs can be tricked to issue false certificates (by gaining control to a mailbox or DNS).

I don't think this can be fixed on the Thunderbird application side.

The expectation of PKI is that you only trust CAs that you consider sufficiently diligent for your purposes.

In a closed, strictly controlled corporate environment, you'd have to use a deployment in which email clients only trust your own corporate CA (which can be operated in a way that performs stricter identity verification), and mark any public CAs as untrusted for S/MIME certificates (remove the email trust flags provided by the Mozilla CA list).

This model (only rely on corporate CA) fails as soon as you need to communicate with S/MIME across organizational borders. If you cannot trust other CAs to perform identity verification in a way that seems appropriate to you, then S/MIME doesn't work for you.

It seems fair to say, today's security model of public S/MIME certificates relies on no active attacker to ever obtain a false certificate. Given how easy it is for many network/server administrators to obtain an email in transit, I agree that it's not a good idea to rely on that.

We could potentially downgrade the security indicators we're showing. We're currently working on OpenPGP, and have suggested to distinguish between public keys that have been fully verified by yourself, and public keys that you simply assume/hope to be correct.

We could decide that for all public CAs we change the visible indicators to a weaker "unverified identity" level. In a first step, we could do that for S/MIME in general. Potentially, as a future enhancement, we could allow users to mark a CA as "I trust this CA to perform strong identity verification", which could then result in the stronger indicators being shown with email. Deployments could control which CAs get that stronger flag, resulting in stronger identity reliability indicators shown in email.

Currently I think we shouldn't start to offer manual verification for the S/MIME certificates of your conversation partners, because that's now how S/MIME works. Thunderbird would be the only app doing so (right?) and that could confuse users in environments with controlled S/MIME deployments. If users want to do the manual verification, they should switch to the (pending) OpenPGP support.,

(In reply to Kai Engert (:KaiE:) from comment #21)

The security model of S/MIME and TLS relies on the hope that nobody will create false certificates, intentionally or unintentionally.

This bug report is a complaint that "hope" isn't secure, because CAs can be tricked to issue false certificates (by gaining control to a mailbox or DNS).

I don't think this can be fixed on the Thunderbird application side.

The expectation of PKI is that you only trust CAs that you consider sufficiently diligent for your purposes.

I think the crux of this attack is that people think a class 1 certificate provides more assurance than it actually does.

A class 1 certificate guarantees that your email service has not tampered with the message and cannot alter it. It also guarantees that the message comes from your peer’s email account, rather than from a spammer spoofing their From: address. It does not (and cannot) guarantee that the holder of the certificate is the person who ought to have control of the account. For that, you need a higher level of validation: either an OV or EV certificate, or a certificate signed by a private corporate CA.

The DV model works for TLS because certificate transparency means that no browser will trust a certificate unless it has been placed in a publicly available, immutable, and signed log. It is therefore possible to reliably know of every TLS certificate that has ever been issued for one’s domain name, and trigger an alert if a rogue one is ever found. There is no such mechanism for S/MIME, and I am not certain if one can exist.

In a closed, strictly controlled corporate environment, you'd have to use a deployment in which email clients only trust your own corporate CA (which can be operated in a way that performs stricter identity verification), and mark any public CAs as untrusted for S/MIME certificates (remove the email trust flags provided by the Mozilla CA list).

This is what I would do, though it is admittedly a poor workaround.

This model (only rely on corporate CA) fails as soon as you need to communicate with S/MIME across organizational borders. If you cannot trust other CAs to perform identity verification in a way that seems appropriate to you, then S/MIME doesn't work for you.

Indeed so.

It seems fair to say, today's security model of public S/MIME certificates relies on no active attacker to ever obtain a false certificate. Given how easy it is for many network/server administrators to obtain an email in transit, I agree that it's not a good idea to rely on that.

We could potentially downgrade the security indicators we're showing. We're currently working on OpenPGP, and have suggested to distinguish between public keys that have been fully verified by yourself, and public keys that you simply assume/hope to be correct.

We could decide that for all public CAs we change the visible indicators to a weaker "unverified identity" level. In a first step, we could do that for S/MIME in general. Potentially, as a future enhancement, we could allow users to mark a CA as "I trust this CA to perform strong identity verification", which could then result in the stronger indicators being shown with email. Deployments could control which CAs get that stronger flag, resulting in stronger identity reliability indicators shown in email.

I think there is a hybrid approach that might work (disclaimer: I don’t use S/MIME myself):

  1. Mark all class 1 certificates as unverified. A class 1 certificate guarantees that your email provider has not tampered with anything, but it guarantees nothing if your peer’s email provider can tamper with stuff.
  2. Allow users and/or deployments to mark CAs as trustworthy for specific domains. A corporation will mark its own CA as trusted for its own domain, so internal email will be marked as trusted.
  3. Provide yet another indicator for publicly trusted EV and OV certificates. These presumably guarantee that the human person who has signed a message is the one you think they are.
  4. Encourage delegation (with name constraints) from publicly trusted CAs to corporate CAs. For instance, if Mozilla has an S/MIME CA (I don’t know if they do), DigiCert (or any other publicly trusted CA) could sign Mozilla’s root with a name constraint only allowing it to issue for @mozilla.org email addresses. Within Mozilla, such certificates would be marked as validated per point 2. Outside of Mozilla, they would be marked as unverified by default, but users could mark the cross-signed, name-constrained as trusted for the domains it is allowed to issue for.
  5. Do not allow one certificate to overwrite another without prompting unless the new certificate has a higher level of validation. 2 and 3 are considered incomparable for this purpose (neither is higher than the other), at least by default.

It is worth noting that most of my focus here is on email signing, because email encryption has well-known and unfixable flaws. The only area I know of where it works well is security vulnerability reporting, and that only because there is no need for forward secrecy (the bugs will eventually be made public) and metadata leakage is not very useful to an attacker.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.