Re: Multiple Gmail accounts would individually require confirming the same new certificate. Was that behavior changed in the earlier change.
No, cert tracking is still per-account (per server endpoint actually).
Why not have it combined? I might be missing something, but I do not see any security problem if for
exactly the same server and port (which I assume you call the endpoint), - you can have "combined" acceptance: i.e. if I accepted a new cert in one account, and another account has the same server and port, - it would be considered accepted.
On my phone, I have three different Gmail accounts in Aquamail (all using the same Gmail imap servers, and two of them using the same Gmail MTA/SMTP servers), and two other accounts using the same imap and smtp servers between the two.
One detail I am still not sure about is if the end point is different (e.g. by the port number, imap vs smtp, or by the host alias, e.g. imap.domain.com vs smtp.domain.com), but the certs are the same, - is there any reason to separate acceptance for them in case of a new (but the same) cert.
Re: as long as the name matches
Not at all.
As it says above: "based on the hash / signature".
( and even if it were, it won't be less secure than the proposed per-account "skip the check" option... but it isn't based on the name )
I understood that you are using the hash, - I just labeled it with the "server name".
I think that it would be a good measure for many Aquamail users. (I've never said that it is less secure than per-account "skip the check".) My questions were not meant to be against it, rather to understand the current status of cert checking. And, after thinking more about it, my suggestions would be about things complementary to this new change: (1) an option of manually enable the "old" behavior (i.e. keep cert-change warning even in Gmail), and
(2) [for all other accounts] have per-account "skip-the-check" option.
Additionally (3), - further improve checking of the newly issued cert by verifying the has of the CA (that the CA has not changed).
In more detail:
(1) Why this newly implemented check might be insufficient for security-extremely-conscious users?
I think that the check in some cases is not doing what you want it to do. (Sorry, I will repeat the basics that you know, but I will use that as a foundation for my argument)
The intent for tracking cert change is a MITM (man in the middle) attack.
There are two most anticipated cases for that (with a rogue cert) that are using valid CAs:
1. A cert is completely different (i.e. issued for a different entity, could be by the same or a different CA). Your newly added check detects that.
2. A cert is trying to match a well known cert (such as Google), and issued in the same name, but by a different (but still valid) CA. As far as I understand, your newly added check would not detect that.
There have been known cases like that (See e.g.
https://arstechnica.com/information-technology/2014/02/in-the-wild-phony-ssl-certificates-impersonating-google-facebook-and-itunes/ ) where a less-than-thorough (or politically or otherwise motivated) CA was used to issue valid certs impersonating those of Google, FB, etc.
Yet another example is an approach like this:
https://www.wired.com/2010/03/packet-forensics/The weak point exploited in these cases is subordinate CAs. The (subordinate) CAs questioned by the security community belong to CNNIC (was removed after an incident in 2015), Etisalat, as well as those issued to some US defense contractors etc.
(Of course, there are other scenarios that are based on attempts of impersonating CAs, but those cases should be caught by "strict SSL checking".)
That's why I suggest to keep an option of getting warning about cert change as before.
Actually, one other idea on how to improve the check is to also verify that the CA's hash is the same. When the cert is replaced, Aquamail can check both the hash for the cert name (organization), as you've recently implemented, and the CA's hash.
Furthermore, I suggest that you would implement these two checks (for the server's cert name hash and for the CA's hash) for
all accounts when "track the cert change" option is enabled. So, if the cert has changed, Aquamail would check that both hashes are the same as before.
Next, if the option "track cert change" is enabled, Aquamail would display the old and the new certs, and will show a confirmation for the hashes unchanged or otherwise a warning that either or both have changed.
If the option is not enabled, Aquamail would warn only in case at least one of the hashes has changed.
Finally, some other accounts are also using frequently changing certs (e.g. those who are using Let's Encrypt's certificates are rotating them about every 2 months). And this trend is going to extend (due to the forward secrecy). Hence the request for the "per-account" option.
There are users who discover the "track SSL cert changes" setting and think "Oh cool! Some kind of security thing, I want that!".
Some time later (and very soon) they get the "cert change" message for their Gmail account(s).
And then:
- They don't make the connection to the setting - even though they enabled it themselves
- They have no idea what it is - even though there is an explanation in the FAQ
- They think the app is "broken": "since last update can't connect, good app but you need to fix the Gmail error" (and this "since last update" we get a lot)
- Overall - a feature / setting wanted / appreciated by the more knowledgeable users causing trouble when enabled by the less knowledgeable ones.
These people won't ever be able to find the proposed "per account exception" setting.
I understand that problem perfectly.
And I understand that it creates a significant inconvenience for you. But that's what you have to deal with when you have a software that is not dumbed-down (like e.g. Microsoft Mail in Windows) and thus appeals to power users. I assume you are familiar with the saying: "Make a software that even a complete idiot would be able to use, and only idiots would be using it."
Look how some software (e.g. Firefox, Chrome, Android, Windows etc.) are dealing with the options for power users (vs. most common users): Some options are behind an extra step (obscure way of getting access to those options) and/or accompanied by a strict warning ("you are entering a dangerous zone, do not change unless you know what you are doing, all warranties are void, ... ")
---------------
I"ve given some presentations on the security aspects related to TLS- (aka SSL) based secure communication, and I've been showing that only 2 e-mail clients (that I could find) have a unique feature of tracking SSL change: Aquamail (Android) and Claws Mail (Unix, Windows, ...).
I understand and support the change you just introduced. It is needed by many (if not most) Aquamail users. But the question is: are you willing to circumvent this unique powerful feature that Aquamail has had for long time even for the "power-users" who want to have it?
(Well, I've seen that you've already sacrificed yet another unique feature important for some Aquamail users, so, I wouldn't be
completely surprised, but I am still hoping and relying on your best judgement.)
tl;dr: I encourage you to:
1. Keep TLS cert change feature available as an option even for Gmail accounts.
2. Make TLS cert change feature configurable per account (for all other accounts).
I also propose to:
3. think about implementing CA hash change tracking.
4. implement pinning of both hashes for all accounts.
Sorry for the long post. I've been actually improving on some of the ideas I am proposing while writing about them. I hope it is clear enough, but I'd be happy to explain if something is ambiguous.
