Drop support for accepting untrusted certificates

[cketti]

The topic of how to handle untrusted certificates recently came up again, e.g. in #1818.

I was talking to @eighthave about this today. He suggested to simply drop support for accepting untrusted certificates. And the more I think about it the better i like the idea. It'll remove the choice users are most likely unqualified to make anyway and puts the pressure on the people who maintain the server. The server is the place where the problem needs to be fixed. In the age of Let's Encrypt everybody has the option to use a valid certificate.

So my question: Is there a good reason why we should keep the ability to manually accept bad certificates?

[philipwhiuk]

Android devices are dependent on their manufacturers to push new global root certificates I think. Many manufacturers probably don't do this.

I think you'd be enforcing obsolescence. We're likely to see this increasingly often due to the long tail of Androids ecosystem.

As an app developer we can't control the level of post purchase support given by device manufacturers.

I prefer the browser approach where you warn heck out of it but you still allow it happen.

What do other email applications do here?

As an aside, if we are dropping untrusted certs on the basis of Let's Encrypt we should also dropped unencrypted traffic period. Untrusted certs are not really worse.

[eighthave]

I can no longer see any good reason to support self-signed certificates. use letsencrypt. period. Supporting self-signed certificates or CAs that are not in system keyrings is just weakening everyone's security.

[ArchangeGabriel]

The problem is, as @philipwhiuk said, that some CA might not be in the system keyring because the Android version is too old for some new CA.

[chadwickblane]

weakening everyone's security

https://darkmail.info

Is that a step in the right direction?

[philipwhiuk]

We already have a ticket for implementing DMIME. The spec is horribly incomplete. It's several years off production I expect.

[eighthave]

sure, then in that case, people using those CAs can just switch to letsencrypt.

[ArchangeGabriel]

@eighthave I’m not sure how long will Let’s Encrypt Root Cert be cross-signed by another CA. I would expect it to end at the EOL of current Root Cert, at which point any old device will have issue with this. Maybe that a reason for them to keep it cross-signed though… Anyway, there might be people not able to get a cert from Let’s Encrypt for whatever reason (IDN — though I think they were some progress on this —, site in .onion or .42 or whatever — but probably rare to have a mail server on those —, etc.).

That being said, I’m would love K-9 to drop unencrypted connection, untrusted certs… I’m only advocating for the devil above, and in the end maybe what could be done is dropping support and then see if anyone actually complains.

[gdt]

One thing to keep in mind is the difference between K-9 having a way to accept a certificate that cannot be validated from a configured trust anchor, and users not being able to use certificates other than those issued by CAs that other people approve of. For example, it's IMHO perfectly reasonable for a person or an organization to create their own CA cert and sign certificates for a bunch of their own machines. Or to add in one's national CA if it isn't in the default set. But in these cases, you can add the private CA cert to android, in which case K-9 doesn't care that it isn't in the default trust anchor set, and you still get validation of individual certificates.

So, as long as it seems reasonably expected that adding a private CA cert as trusted will continue to work, I don't see any need for K-9 to have an additional override mechanism.

Also, if this is about the UI and safety, vs about reducing code complexity, it could be an expert mode toggle, defaulting to off. But I can see the desire to rip out the code.

[gdt]

Also, I think the points above about unencrypted connections being even worse than self-signed certs are valid. So if the point is reducing code complexity because almost no one uses the feature and the risk of bugs/confusion outweighs the benefits, fine, but if it's about better security for users that aren't sophisticated enough to understand PKI (which would be almost all), then it would seem that dropping all support for non-TLS would be a bigger improvement. And that seems a bit much, since I can't confidently tell people who choose to read mail over non-TLS (rather than not read mail) are wrong, in the general case and not knowing their detailed situations.

Plus, the notion that every single one of the CAs in the default trust anchor set are trustworthy is highly questionable. Of course, that's not K-9's issue either, unless you consider the lack of pinning a bug. My point really is that the PKI world is very messy, and it's not entirely fair to draw a bright line of "secure behavior" and "insecure behavior".

[eighthave]

I agree with @gdt. Also ditch support for unencrypted connections. Email is an ecosystem, and it is sick and dying because we continue to let some members of the ecosystem behave really badly (allowing no encryption, etc). If we don't fix it, users will stop using email, and we'll end up with almost everyone using proprietary silos controlled by big companies that collaborate with mass survellance (whatsapp, facebook, wechat, gmail, etc).

As for self-signed and custom CAs, Android provides ways for people to add their own CAs. K-9 won't handle it better than Android.

[eighthave]

and the other key question here, how many people are there who match both:

• are currently using mail servers with self-signed certs
• have devices older than Android 4.2

I'm sure the answer is very few. And for those very few, we do not need to force them off of email, we just need to help them install Lets Encrypt as a user CA in Android.

[Valodim]

I'm usually all for getting rid of legacy security workflows, but my first intuition is that this is a little radical.

We have no idea how many users' workflows this will break, how many of these are benign (as in, not caused by actual attackers), how many of these are able to even fix the problems on their server. I also don't think "just use letsencrypt" is an acceptable support response. Not everyone is in a position to have an up to date android phone, or find out how to install a custom CA, or "fix their mail server".

[eighthave]

No one is saying "just use letsencrypt" is the only answer here. The key point is to not duplicate the functions that others are providing much better. Android lets users add CA certs, letsencrypt lets users have real HTTPS certs.

For people not in a position to fix their mail server, there are lots of good hosting services that support free software, like https://fastmail.com.

And yes, a very small number of users will be stuck between a rock and a hard place because of these changes. I see no good reason to spend a large chunk of the very limited dev resources on those cases, since it requires weakening everyone's security.

[cketti]

Of course this will affect users. And most of them will probably blame us because we broke what "worked" before. But my opinion is that those things are broken and shouldn't work anymore.

I didn't explicitly mention this before, but of course I also want to drop support for unencrypted connections. Otherwise people will just fall back to that.

If it turns out there's a real need to support broken setups and that need can't be satisfied by other apps, someone will have to create and maintain "K-9 Mail Legacy". But I like to develop for the future rather than the past.

[vext01]

I think you will upset users who are self-signing.

[yoshimo]

Valodim is right, outright killing it is too radical. We also saw similiar things when old ciphers where disabled recently. People want it to "just work". maybe we could get back to this once we support DANE TLSA to pin certs as suggested in #1776#

[Frogging101]

I use a self-signed certificate with my self-hosted email. I know exactly what I'm doing. Do not remove my ability to do this.

[Frogging101]

And I don't trust Google to continue to give me the option of adding my certificate to the system trust store. Who's to say someone over there won't come up with a similar bright idea to remove that too.

[ArchangeGabriel]

And I don't trust Google to continue to give me the option of adding my certificate to the system trust store. Who's to say someone over there won't come up with a similar bright idea to remove that too.

That won’t happen because companies need to be able to add their CA/certs.

[eighthave]

yeah, all of the banks would stop using Android if they did that. Banks (in the US at least) have to monitor a lot of their employee activity by law.

[ssb22]

Cambridge University just changed their mail server certificate to one issued by QuoVadis which is not recognised by Android 4.4. This is going to be a problem with many UK universities as QuoVadis now supply JISC. Thankfully if I go to K9's Settings / Account settings / Fetching mail / Incoming server / Next (and Settings / Account settings / Sending mail / Outgoing server / Next), I can accept the new certificate like a self-signed one. Please do not remove this, because the chances of persuading UK universities to switch to an Android 4.4 compatible certificate provider are remote.

[brianscottwilson]

I can think of a really good idea to let the user decide what to trust when it comes to certs. One of my (oldest and widely distributed) email addresses is uses self signed certificates as the company is technically bankrupt, but has grandfathered existing email accounts. I know what I'm doing when I accept this and I will happily give up K9 rather than lose all my business contacts that send email to this account (of more than 20 years).

If you want to get involved, it is your job to explain the possible issues involved with SSC's. It is not your job to decide for me whether or not to accept SSC's. That is the user's choice to make (unless you're Microsoft).

[ckujau]

This issue is already way too long, but I still want to make a case for supporting self-signed certificates: I run my own mail server, but the IMAP port is not opened to the outside world on purpose and I use ConnectBot on Android to establish an SSH tunnel first to then fetch (and send) emails with K-9.

Sure, my server has a valid Let's Encrypt certificate, but that won't ever match localhost:1993 and right now there is always a prompt to accept or reject that mismatch, every time. I assumed this to be that way because the LE certificate is of course renewed every now and then and the fingerprint chsnges, and maybe that's why K-9 prompted so often. I issued myself a self-signed certified certificate to be valid for some years, but this too of course causes a prompt to accept or deny this certificate.

Initially I came here to whine about why it prompts way too often for this self-signed certificate, but stumbled across this issue instead and wanted to oppose removing support for the same altogether ;-)

[brianscottwilson]

Good afternoon:

I wish to second the motion to continue support for self-signed certificates.  I use an email service run by a friend which uses these certificates as we are a non-business email system.  Without this support, I would have to drop K9, and my financial support of the product.

--

Please contact me if you have any questions or concerns.

Sincerely,

Brian S. Wilson Primary: @. (preferred) Secondary: @. Tertiary: @.*** Phone: +1 (678) 376-9258 Mobile: +1 (678) 232-9357 Address: 1900 Grouse Ct. Lawrenceville, GA 30044-6914

---

This message has been digitally signed as a security measure.

---

On 1/7/2022 12:43 PM, Christian Kujau wrote:

This issue is already way too long, but I still want to make a case /for/ supporting self-signed certificates: I run my own mail server, but the IMAP port is not opened to the outside world on purpose and I use ConnectBot on Android to establish an SSH tunnel first to then fetch (and send) emails with K-9.

Sure, my server has a valid Let's Encrypt certificate, but that won't ever match |localhost:1993| and right now there is always a prompt to accept or reject that mismatch, every time. I assumed this to be that way because the LE certificate is of course renewed every now and then and the fingerprint chsnges, and maybe that's why K-9 prompted so often. I issued myself a self-signed certified certificate to be valid for some years, but this too of course causes a prompt to accept or deny this certificate.

Initially I came here to whine about why it prompts way too often for this self-signed certificate, but stumbled across this issue instead and wanted to oppose removing support for the same altogether ;-)

— Reply to this email directly, view it on GitHub https://github.com/k9mail/k-9/issues/2361#issuecomment-1007602071, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG3OJKTMOEM3IEE2JMJZ2QTUU4Q2LANCNFSM4DC4LCMQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[Kyle2142]

Many times people cite let's encrypt as the answer yet k9 (latest version) on my device (Android 10) prompts me sometimes to allow my self hosted server's certificate (which is by LE). Something about untrusted root CA.

So I agree with many on this issue: feel free to drop plaintext but I'll move elsewhere if untrusted certificates are completly disallowed

[cketti]

When using a Let's Encrypt certificate, you shouldn't be getting a certificate error on Android 10. Ignoring security-relevant errors is never the right thing to do.

Try to find out why you're getting the error. If you need help, please use the forum. See e.g. https://forum.k9mail.app/t/k9-mail-one-cert-for-all-domains-postfix-dovecot/4092

[brianscottwilson]

On 2/3/2022 5:27 PM, Kyle2142 wrote:

So I agree with many on this issue: feel free to drop plaintext but I'll move elsewhere if untrusted certificate prompts are completely disallowed

I second the motion.  I use a private email service that has self signed certificates.  It is fine if I get a warning and chose to accept such certificates, but the day any mail client starts dictating that we all have to pay huge fees to a hand full of monopoly trusted certificate companies just so we can read our own mail is the day I stop supporting that mail client.

--

Please contact me if you have any questions or concerns.

Sincerely,

Brian S. Wilson Primary: @. (preferred) Secondary: @. Tertiary: @.*** Phone: +1 (678) 376-9258 Mobile: +1 (678) 232-9357 Address: 1900 Grouse Ct. Lawrenceville, GA 30044-6914

---

This message has been digitally signed as a security measure.

---

— Reply to this email directly, view it on GitHub https://github.com/k9mail/k-9/issues/2361#issuecomment-1029460182, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG3OJKSUANBFHI4LJNMZ4RDUZL6N5ANCNFSM4DC4LCMQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you commented.Message ID: @.***>

[ArchangeGabriel]

If you use self-signed certificates, you should make an self-CA (using e.g. easy-rsa) and add that CA to your system. That would be more safe.