K-9: 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).