'SSL certificate has been changed' notification driving me crazy...

[Kostya Vasilyev]

OK, we'll try it.

[StR]

That sounds reasonable.

FYI:
I just discovered that a desktop e-mail client Claws Mail has a similar (very rear) functionality.
But they have had this detection enabled (period). In response to the Gmail "problem", they introduced a per-account configuration option: 'automatically accept valid SSL/TLS certificates'.  So, the logic of the option is sort of opposite.

@Kostya, please do not overlook the suggestion for making this per account option.

[Kostya Vasilyev]

Re: Claws

Yes, maybe, but I'm not completely sure if more complicated and elaborate is the answer here, and if any "answer" is needed at all -- I mean they're not changing their certs once a day or once an hour (yet, maybe they will).

Now, there used to be "special case" code that would automatically accept any changed certs if they'd been issued by Google's issuer. Does this seem like a reasonable thing to do (and resurrect, given the changed circumstances)?

[mikeone]

Re: wording:

Maybe "SSL certificate change detection"?

German translation:

SSL-Zertifikatsänderungen erkennen

[Kostya Vasilyev]

Thank you @mikeone

[StR]

Re: Claws

Yes, maybe, but I'm not completely sure if more complicated and elaborate is the answer here, and if any "answer" is needed at all -- I mean they're not changing their certs once a day or once an hour (yet, maybe they will).

I am confused by this comment, Kostya. I don't understand it.
So, let me clarify what I meant by the reference to Claws.
I don't think, at present, Claws does much differently from what Aquamail is doing. The two differences are: 1. The "default" is the opposite for detecting change of the certs, and 2. This setting is per account.
I am not saying you must match #1. (Actually, below I am suggesting that you might consider something in between). I was just sharing the related knowledge about how it is done elsewhere.

Now, there used to be "special case" code that would automatically accept any changed certs if they'd been issued by Google's issuer. Does this seem like a reasonable thing to do (and resurrect, given the changed circumstances)?

I'd say, no. There are two reasons for this:
1. Someone might still want to verify that even for Gmail him/herself. Even though the percentage is extremely small, but since you have the mechanism in place, why deny that possibility?

2. I expect that several other providers will follow this suit soon. (And not only because of Gmail's trend, but also because of Let's Encrypt (and other similar initiatives) popularity.
That's why, having it configured per account would be a more reasonable (long-term) solution, IMHO.

What you might consider is disabling it by default for Gmail accounts and enabling for the rest. (I understand that the present default is "disable".)

[Kostya Vasilyev]

Well, what we see happening (through our support mailbox) is --

-- for the users who understand what this does, the weekly Gmail cert changes are not a problem.

-- it is a problem for the users who enable this setting and don't know what it actually does (and don't check the FAQ either), and then think that "this app is broken" or "you guys need to update your certificates, Google says they're out of date", etc.

I don't like the idea of special casing Gmail again because -- right now, without that special case, the app actually shows you what is really happening, it doesn't try to create a distorted albeit more comfortable view of reality.

Will give more thought to the idea of a way to turn this off per-account, but then again -- the security minded will still want this enabled, for all accounts, because -- I'm theorizing -- being security minded, they most likely prefer "more realistic" to "more comfortable".

[Kostya Vasilyev]

This new build has the updated wording (EN / FR / DE):

https://www.aqua-mail.com/forum/index.php?topic=5379.0

[StR]

I don't like the idea of special casing Gmail again because -- right now, without that special case, the app actually shows you what is really happening, it doesn't try to create a distorted albeit more comfortable view of reality.

I don't have problem with that view. My suggestion for a different default was just a thought in response to your question about enabling a special workaround.

Will give more thought to the idea of a way to turn this off per-account, but then again -- the security minded will still want this enabled, for all accounts, because -- I'm theorizing -- being security minded, they most likely prefer "more realistic" to "more comfortable".

Let me provide you some information about that.

1. I am security-minded. I've had this option enabled from the beginning (and in the recent days couldn't even find it - hence my earlier question).
But I am close to being ready to give up on Gmail (probably all Gmail accounts).  But I don't want to disable the change detection for the rest of the accounts.

2. In the past few days, I've been doing some quick research on some related security issues, including which software tracks change of the SSL certificates, and how it deals with the frequent changes started by Google a few years ago.
So far, besides (almost?) all implementations of SSH and Aquamail, I was able to find "Certificate Patrol" plugin for Firefox and Claws Mail.

"Certificate Patrol" plugin is obviously installed only by security-minded people. I found numerous accounts of people turning that plugin off soon after Google started rotating SSL certs on their websites.
As I wrote above, Claws introduced an option to automatically accept the new cert for an individual account. (In a direct conversation, one of the Claws developers told me that it was a direct response to Gmail's certificate frequent change "problem".)

Security vs. convenience is always a balance, a compromise.
My impression is that, except for the "most security-minded" (almost paranoid), - many security-minded people would switch off this option for Gmail, while keeping the rest of the accounts enabled. But then, many "security-paranoid" people do not use Gmail at all. Gmail is already a compromise toward convenience...


Let me add yet one more use case:
Besides the annoyance, there is yet another issue caused by the present behavior (Aquamail + Gmail): I have one Gmail account with a very low flow of messages, where I need reliable (i.e. relatively quick) notification. This is the only account for which I have a sound notification for new  messages, so that I can hear the new message even if I am in a meeting, driving on the road, etc. (i.e. not looking at my phone).
Since the cert-related error can go unnoticed for a while (well, I'd have to look into that, maybe there is a per-account sound alert for errors? But even that might not be a good solution), I would not know about the new important message in that account. In this account, the reliability of quick notification is more important to me than the safety (and the risk of a MITM attack).

For now, I keep that account (the only one) in the Gmail app.

(Actually, there is a second reason as well: absence of separate (per account) options for IMAP synchronization on the mobile network. At the moment, that Gmail app is receiving notifications on the mobile networks, while Aquamail, with the rest of the accounts, is not. I suggested the per-account mobile-network settings for IMAP very recently - when I transferred one other account to Aquamail, for which I'd prefer syncing on mobile network. But that is a separate issue.)

[Davey126]

Will give more thought to the idea of a way to turn this off per-account, but then again -- the security minded will still want this enabled, for all accounts, because -- I'm theorizing -- being security minded, they most likely prefer "more realistic" to "more comfortable".

Saw @StR's response and wanted to comment on the above. I agree with not creating a special case for internally handling frequent SSL rotation thereby obfuscating reality and calling into question (for some) the critera used to determine if a certificate change is truely benign. Allowing SSL validation to be disabled on a per-account basis would seem the best option. In my experience most individuals with security mindset understand Gmail is not the service of choice if privacy is a concern. Security and privacy are two different things. That said, those unconcerned with one tend to hold a similar opinion of the other.

[StR]

Allowing SSL validation to be disabled on a per-account basis would seem the best option.

Please excuse me, I would correct where you mis-spoke: SSL cert validation and change detection are separate things. You meant to say "SSL cert change detection" here.
(SSL cert validation is already an option for each account - set as "strict checking" under account options (SSL vs SSL (strict checking)).)

In my experience most individuals with security mindset understand Gmail is not the service of choice if privacy is a concern. Security and privacy are two different things. That said, those unconcerned with one tend to hold a similar opinion of the other.

Good point about separation of security and privacy.
Because of questionable privacy, Gmail can be used even by the most security- and privacy-minded for unimportant e-mail messages (e.g. subscription to mailing lists, etc.) and other auxiliary purposes.

As an aside, some security measures actually sacrifice privacy. One example related to dealing with potentially "bad" SSL certs is a Firefox plugin CheckmyHTTPS. It checks the new cert that the browser encounters against the database of known certs stored on the project's server, and informs if this cert had not been seen by anybody else before (even if it appears valid otherwise). But the user essentially shares his/her web browsing pattern with the entity behind this project.

[Davey126]

Allowing SSL validation to be disabled on a per-account basis would seem the best option.

Please excuse me, I would correct where you mis-spoke: SSL cert validation and change detection are separate things. You meant to say "SSL cert change detection" here.
(SSL cert validation is already an option for each account - set as "strict checking" under account options (SSL vs SSL (strict checking)).)

Yes - got sloppy (casual) with the wording. Believe "SSL certificate change detection" under Settings->Network is what is being discussed. As for "SSL cert validation" that option does not appear to be present for Gmail accounts.

[StR]

As for "SSL cert validation" that option does not appear to be present for Gmail accounts.

You are talking about Gmail account when OAuth mechanism is used for authentication (as opposed to a generic IMAP account). I don't know OAuth mechanism in as much detail as I know IMAP-SSL authentication, but it is different, and that's likely why that is not an option.

[Davey126]

As for "SSL cert validation" that option does not appear to be present for Gmail accounts.

You are talking about Gmail account when OAuth mechanism is used for authentication (as opposed to a generic IMAP account). I don't know OAuth mechanism in as much detail as I know IMAP-SSL authentication, but it is different, and that's likely why that is not an option.

Yep - OAuth is easy, quick and reasonably secure. Best choice IMHO for the 99% of the Gmail community. Purests hate it (of course) but the vunerabalities are mostly therotical and/or behavioral which somewhat laughable when put in context of the stereotypical Gmail user.

[StR]

Yep - OAuth is easy, quick and reasonably secure. Best choice IMHO for the 99% of the Gmail community. Purests hate it (of course) but the vunerabalities are mostly therotical and/or behavioral which somewhat laughable when put in context of the stereotypical Gmail user.

I am not a "purist". And my experience with OAuth is very limited. But a quick Google search indicates that improper implementation of OAuth (which happens a lot!) by apps and website can result in many compromised accounts. And that's a situation where you, as a user have very limited recourse (short of not using any of those resources or OAuth).
See, e.g., http://homakov.blogspot.com/2012/07/saferweb-most-common-oauth2.html (note the list of popular websites that had an improper implementation: pinterest, digg, soundcloud, bit.ly, etc.) and https://threatpost.com/oauth-2-0-hack-exposes-1-billion-mobile-apps-to-account-hijacking/121889/