Improve error reporting on TLS connection errors

[cketti]

Since we want everyone to use secure connections we have to make it easier for users to learn what exactly was preventing a secure connection from being established. Ideally we also point them to an online resource to learn how to fix the problem.

[ocdtrekkie]

As in the other issue I'd definitely point people to ssllabs for additional information. If you wanted to go the extra step, you can create a link for them that goes directly to an analysis of the server in their account settings.

[cketti]

I believe that's too low-level for many users. I'm hoping some organization will start a site dedicated to helping end users with TLS connections issues so we can link to it.

[ocdtrekkie]

I haven't looked into too much detail, but they have an API. I suppose someone could whip up a thing that looked at your Android version, compared it to the SSLLabs test result for your platform version, and get a more specific answer. I'm not sure how much you can abstract away "x doesn't support the 3DES cipher" or similar though.

Also SSLLabs seems to have a bug in reporting for Android 5.0 and doesn't have later versions. So they have work to do too.

I just figured a generic answer that your email client and your email server's security settings are not compatible, with an advanced link to SSLLabs would be suitable. Nobody short of a system administrator is going to be able to change the Exchange server configuration, so the cipher stuff has no real need to be in layman's terms.

[philipwhiuk]

I'd like to see something like this

to replace AccountSetupCheckSettings.acceptKeyDialog()'s attempt at showing certificate chains.

I agree with @ocdtrekkie that we need to be careful about how we target this stuff and we likely want to follow browser best practice here.

[lbort]

I am not entirely sure where to state this, it equally affects #1818, and originally is a reaction to a comment in #2467: There are more failure modes of TLS than "expired" or "self-signed", and they all should be treated as transparent and informative as possible. Below some cases that come to my mind right now. Some of them imply that certain things are implemented (cert pinning & checking for revoked certs).

• server serves a valid but wrong cert that does not match the hostname. This could be a misconfiguration by the server, or an attack.
  • This should trigger a big warning, since it most probably is something bad. Especially if the server presented a cert that worked before I would be ok if there is no option to continue the connection at all.
• server serves a valid cert, which is not the one that is pinned. This could be either a badly implemented change of cert, or - more severe - a sophisticated attack using a rogue CA or fraudulently obtained certs.
  • This should trigger a big warning as well, with the option to override, and maybe even repin the new one? But only with big "I know what I am doing" flags.
• server serves a revoked cert (is this detectable? or is stuff like OCSP-stapling only used in https, but not email?)
  • should trigger a big warning and no way to override.

Probably there are more cases, or there will be more in the future. so being flexible is probably a good idea.

[AndrueCope]

Similar problem here. K9 is refusing to connect to my server giving a really unhelpful 'STARTTLS failed, connection security not available'. If the idea really is 'to encourage users to use secure connections' you have to do better than this. So far K9 is the only application that has a problem with my server and various online tools rate my server as B+ with no certificate issues on IMAP or SMTP.