AquaMail Forum
English - Android => General Discussion => Topic started by: flupke01 on February 04, 2017, 03:37:51 am
-
I use 3 gmail (imap) accounts in Aquamail on my phone, which usually work fine. But since somewhere last summer, aquamail started showing the (for me very) well-known 'SSL certificate has been changed' notification. At first this happened not to often, maybe once every 3/5 weeks. I don't know exactly, didn't keep track of it... Last few months though the frequency of those events went up big time. Now I get those notifications multiple times a week. Sometimes I don't get them for a few days, and sometimes 3 times a day...
I've read all I could find about it. I know aquamail is doing what it is supposed to do. I check the information about the old and new certificate thoroughly, but every time it is the same: the old cert should be still valid and the new one is obviously valid too. And both are from Google, like they should... Nothing suspicious there. Only strange thing is that the old cert is not expired yet. Most of the time I check the certs, accept the change and aquamail is fine again. But I found recently that sometimes not doing anything also works; after some time the notification just disappears and mail is being checked normally again...
I should also mention that this behavior also occurs on my tablet, and on my wife's phone and tablet.
I always used to have ssl set up as 'strict', but am now going to experiment with ssl accepting all, for just one of my gmail accounts; see what happens...
If anyone has a clue what I could do to get rid of this (amount of) notifications without lowering the security settings, I would be very, very happy to hear about it. This is so annoying. I get it if Google change the certs from time to time, but this frequency is ridiculous...
-
It's not only with Gmail. I'm having the same problem, repeatedly.
I've used Aquamail for years and this only started happening recently. I wish I could go back to an earlier version.
-
If anyone has a clue what I could do to get rid of this (amount of) notifications without lowering the security settings, I would be very, very happy to hear about it. This is so annoying. I get it if Google change the certs from time to time, but this frequency is ridiculous...
It's not only with Gmail. I'm having the same problem, repeatedly.
I've used Aquamail for years and this only started happening recently. I wish I could go back to an earlier version.
Nothing to do with recent builds. Google regularly rotates SSL certificates (annoying). Best solution IMO is is to deselect 'SSL validation' in security settings. Yes, this removes a layer of security but others remain. Assess the exposure and decide if the benefits outweigh the risk. There are other ways to detect MITM attacks if you are seriously worried about that.
-
Let me respond to previous posts in an attempt to explain what is happening. (I believe in knowledge as a basis for decisions.) And to propose an option to Kostya:
1. It is not the client. It is the servers. It used to be that the SSL certificates on the server were valid for 1-3 years, and they were replaced just before they were expiring. Recently Google started changing them about once a month. I agree, it's a bit annoying. (And then, you get a chance of seeing flip-flop if you happen to connect to a server with a new certificate, then to one with the old one, and then again to the one with the new one, -- could be on the same day.)
At the same time, there is a push toward moving all web traffic from http to https. For this reason, many websites who had never had SSL certificates need those. Most certificates are not free. But there is a recent provider, Let's Encrypt, that provides free SSL certificates that are only valid for 3 months: https://letsencrypt.org/
So, you may see many small providers switching to those.
And with the "Let's Encrypt", the automated renewal of certificates happens for those certificates that are less then 1-month before the expiration. That makes the actual life of a certificate to be about 2 months.
2. Before I go to what Aquamail does with the certificates, I need to mention two (or three) roles that SSL certificates play in the secure communications:
a) to encrypt the exchange of information, and
b) to authenticate that the communicating side/participant (server, client) is who it claims to be.
Actually, the latter, has two possible aspects:
i) It is verified through the "trusted authority" that they are who they are (And then there are different levels of that verification, as different Trust Authorities may require different confirmations: some just confirm that the server indeed can control the domain, while others require confirmation of the entity name used in the certificate. But we are not going to go this deep here.)
ii) It is confirmed that it is the same participant (server) as you've already communicated previously (independently of whether it may or may not be verified through a trusted authority).
Unfortunately (b.ii) is largely defeated by the frequent change of the certificates.
Moreover, unfortunately, I am not aware of any web browsers or even any other e-mail clients that inform you about change of the certificate while the new certificate is valid.
I know only two categories of software where this change is tracked: all SSH implementations [that I've seen], and Aquamail.
None of the webservers, none of the e-mail clients (of those that I've seen), none of the "MTA's" (mail transfer agents, i.e. servers transmitting e-mails between servers via SMTP protocol), none of the source control software (here my information is primarily based on my conversations with software developers who use those), or any other software that relies on certificates (SSL).
3. Aquamail behavior with respect to the certificates. I remember reading Kostya's explanation about this behavior, and while I understood (I think) his explanation, I was confused.
Here is a summary of my understanding:
a) Aquamail checks the validity of the certificate. IIRC, that includes the check of the entire chain down to the root certificate. That is done if "strict checking" enabled. (I.e. if the server has a self-signed certificate or a certificate without the root authority known to the device, Aquamail will not continue with the connection.) If the strict checking is disabled, then, essentially the certificate is used to encrypt the password exchange and the rest of the communication, and a self-signed certificate is sufficient.
Then, a separate issue is tracking if the certificate for the server is the same as the one used before. This is a defense for the man-in-the-middle (mitm) attack, where a rogue server is pretending to be the right one. As far as I understand, the logic behind this check is that the rogue server trying to impersonate the target server may have a certificate that may look valid, and might even check out to some valid (known) root CA. That's why Aquamail offers an option to accept or reject the new certificate.
This is a good functionality. But in view of the frequent rotation of the certificates, it becomes annoying, and as a result, it looses its importance, as most users just automatically click on "accept". (You might remember a period when one of the web browsers started by default confirming every cookie it was receiving - and people just turned that off.)
Now, something that I am not 100% sure:
1) I suspect that turning of "Strict checking" under server settings for the account would disable confirmation when the SSL certificate changes. Is that the case?
2) If that's the case, - I'd rather have two separate options: (A) don't be strict on verifying the certificate chain, and (B) do not ask about changing certificate if it is completely verified (probably only in the sense of "strict checking").
In this case one can choose (B) but not (A), and have strict verification without the annoyance from Gmail servers (or potentially many other providers).
(As discussed above, essentially, all email clients that I know implement (B) as the standard behavior without giving an option otherwise.)
@Kostya, I greatly appreciate the fact that the confirmation for the change of certificate exists in Aquamail. This is an indication that you are concerned about security. But it would make great sense to separate the options as proposed above. Furthermore, I'd suggest it would make sense to keep them separate for different accounts (as it is done now for the existing option).
I apologize if I misunderstood and/or missed something in the interpretation of Aquamail behavior/options.
-
@StR, thank you for a great and very accurate (almost to the end) explanation.
Now, something that I am not 100% sure:
1) I suspect that turning of "Strict checking" under server settings for the account would disable confirmation when the SSL certificate changes. Is that the case
Nope. The two validations -- 1) CA "chain of trust" and 2) SSL cert changes -- are fully independent.
The reason SSL cert change tracking exists is precisely because the CA chain of trust can be compromised.
----
Now, StR is completely on the mark with the rest of the explanation.
When you ask Aqua Mail to track SSL cert changes (it is off by default), then that's exactly what it's going to do.
If a particular mail server rotates its SSL certs often, then the "hey look the cert is different" error will trigger after each "new" cert, as expected, but yes it can get annoying.
There is nothing wrong with Aqua Mail's logic here -- if you ask it to track SSL cert changes, then it will.
Please note that since a few months (the previous update, not this 1.8 in "beta"), the app got better about remembering the "already seen" certificates, and should not trigger on back-and-forth cert changes which it did before.
And actually, you can see the difference between the "known" and the "new" certs in Aqua's "SSL cert change, please confirm" dialog.
For Gmail, I see the expiration dates getting bumped every time by just a bit. For example a "known" cert with an April 10 2017 expiration will get replaced by a new one with an April 18 expiration, and so on.
-
Thank you Kostya for the clarification, I knew that those processes were separate; my question was about the configuration option. Recently, I couldn't find the option responsible for tracking the change of the certificate.
Finally, I just have? found it under Settings - Network.
And I think that is what the OP is looking for.
Maybe you can consider making it configurable per account.
For myself, I would consider disabling it for gmail-based accounts, while keeping it enabled for the rest.
-
Thank you Kostya for the clarification, I knew that those processes were separate; my question was about the configuration option. Recently, I couldn't find the option responsible for tracking the change of the certificate.
Finally, I just have? found it under Settings - Network.
And I think that is what the OP is looking for.
Maybe you can consider making it configurable per account.
For myself, I would consider disabling it for gmail-based accounts, while keeping it enabled for the rest.
+1
I second this.
-
Thank you Kostya for the clarification, I knew that those processes were separate; my question was about the configuration option. Recently, I couldn't find the option responsible for tracking the change of the certificate.
Finally, I just have? found it under Settings - Network.
And I think that is what the OP is looking for.
Maybe you can consider making it configurable per account.
For myself, I would consider disabling it for gmail-based accounts, while keeping it enabled for the rest.
Yep - would nice to kill it only for specific providers.
-
found it under Settings - Network.
Which specific setting should be turned off?
-
re: Which specific setting should be turned off?
SSL Validation.
-
@Kostya:
Looking at how the option is called ("SSL validation"), got me thinking that it is a misnomer (for more than 1 reason): First, it is not related to SSL per se, but rather to the SSL certificate, but I can see that you are trying to be brief. But second, and most importantly, - this option is not about validation of SSL certificates, which is controlled by "SSL strict" under account/server settings.
The description of the option is correct, which helps, but not the title.
I'd call it something like: "Track SSL cert[ificate] change", "Warn about SSL cert change" or "SSL cert change warning". (I am trying to make it brief while making it descriptive enough. ... and, of course, correct.)
-
re: Which specific setting should be turned off?
SSL Validation.
Thank you.
-
Please note that "brief" with abbreviation words in English, added to the new translation process (probably web based translalors, not using the app, with poor results) could lead to something totally strange in wording.
Your comment got me thinking about improving that process.
On one hand, you still want to have it brief in English (which sometimes can be jargonish, and as such hard to translate, especially by non-users). On another hand, - you want to have a clear meaning for the translator(s).
(We've seen this even before in this forum, when native speakers were confused about the meaning of the English phrase and were translating it essentially opposite to its intended meaning.)
One solution to that could be to have two lines in the code depository: one that is displayed by the app, and the other one, - a "full sentence" version that is just a comment (never used, never compiled into the app), - to be used as a basis for the translation.
Here it would be:
Display version: "Track SSL cert[ificate] change", "Warn about SSL cert change" or "SSL cert change warning"
Full-sentence version: "Warn about the change of the SSL certificate"
BTW, "cert" is widely used abbreviation, both in the computer world and beyond. See, e.g. Merriam-Webster: https://www.merriam-webster.com/dictionary/cert
-
BTW, for those interested why Google changes their certs so frequently, as far as I understand, the reason is what is called "forward secrecy": https://security.googleblog.com/2011/11/protecting-data-for-long-term-with.html?m=1
My understanding is that frequent rotation of certs forces renewal of the keys that are generated and exchanged upon successful authentication and used to encrypt the subsequent communication.
-
Re: wording:
Maybe "SSL certificate change detection"?
-
OK, we'll try it.
-
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.
-
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)?
-
Re: wording:
Maybe "SSL certificate change detection"?
German translation:
SSL-Zertifikatsänderungen erkennen
-
Thank you @mikeone
-
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".)
-
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".
-
This new build has the updated wording (EN / FR / DE):
https://www.aqua-mail.com/forum/index.php?topic=5379.0
-
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.)
-
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.
-
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.
-
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.
-
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.
-
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.
-
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/
-
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/
Yes - I am aware of the vulnerabilities (albeit not the complete list of 'bad' sites), understand personal exposures (where/when to use OAuth) and have sufficient background to assess the risk envelope. In the presence of a better approach AND absence of careless/carefree/ignorant consumers OAuth would be be improved and/or depreciated. That's obviously not the case as evidenced by the security practices of the vast majority of those who utilize online services. OAuth joins Stagefright, Heartbleed, Badblock, massive MITM coffee shop attacks, etc., etc. being the next 'bad boy' and media darling. What's needed is a radically different approach for online authentication/security which we likely won't see for years or decades.
This is obviously going OT - time to move on.
-
This is getting more and more off topic, but I can't resist :)
- OAUTH and SSL certs are not related to each other (besides the obvious that API calls to refresh OAUTH tokens are protected by SSL, when it is necessary for the app to talk to web APIs for OAUTH2; this is not necessary for Gmail accounts already present in the phone's Settings).
- Gmail requires OAUTH2 for all new accounts, and for old accounts, they've been gradually turning it on (not sure if it's fully completed yet). The wording on the user accessible setting to turn this off is such ("less secure apps") that users get scared.
- Yahoo is following Gmail's lead (except they still haven't provided a way for mail apps to implement it).
So at this point, OAUTH2 is pretty much mandatory for Gmail (and Aqua also supports it for Hotmail and Yandex).
-
Just FYI: I am still using non-OAuth authentication on a desktop and on my phone, in Aquamail.
Actually, Kostya, I have a question about that.
One of the reasons (or, maybe motivations) for that was the following line of thought:
With OAuth2, the authentication to the Google account is handled by the phone itself, and there is a potential for any other app that has access to the "accounts" on the phone may:
1. Realize relation between different Google accounts of mine.
and even
2. Gain access to those accounts (by exploiting some unpatched vulnerability in Android in combination with the weaknesses of OAuth2 [implementation]).
I thought, that the password-based authentication information stored by Android would be less prone to both of those.
Is there a reasonable merit in this consideration, or are the password-based accounts created by Aquamail as vulnerable?
(I am not considering cases when the phone is completely compromised to the level of system/root permissions, when the entire system is accessible to the code with those permissions.)
And finally, with an OAuth2-based authentication in Aquamail, can Google Play service(s) (and, hence other Google apps) on the phone obtain access to that account, or is that Oauth2 token limited to Aquamail? (And, sorry, this is a deeper question: What actually pins it to Aquamail only?)
-
Just FYI: I am still using non-OAuth authentication on a desktop and on my phone, in Aquamail.
Actually, Kostya, I have a question about that.
One of the reasons (or, maybe motivations) for that was the following line of thought:
With OAuth2, the authentication to the Google account is handled by the phone itself, and there is a potential for any other app that has access to the "accounts" on the phone may:
1. Realize relation between different Google accounts of mine.
and even
2. Gain access to those accounts (by exploiting some unpatched vulnerability in Android in combination with the weaknesses of OAuth2 [implementation]).
I thought, that the password-based authentication information stored by Android would be less prone to both of those.
Is there a reasonable merit in this consideration, or are the password-based accounts created by Aquamail as vulnerable?
(I am not considering cases when the phone is completely compromised to the level of system/root permissions, when the entire system is accessible to the code with those permissions.)
And finally, with an OAuth2-based authentication in Aquamail, can Google Play service(s) (and, hence other Google apps) on the phone obtain access to that account, or is that Oauth2 token limited to Aquamail? (And, sorry, this is a deeper question: What actually pins it to Aquamail only?)
It's important to distinguish between authorization and authentication. Native OAuth only provides the former. Another layer (OpenID is often mentioned) is required for authentication if that functionality is required.
Unlike desktop operating systems I don't believe Android provides a native mechanism to store/secure application passwords. I believe it is up to the app to take appropriate measures.
As an aside I ran across this article while trolling the web. Note the positioning of AquaMail and additional kudos given to the clarity of the Privacy Policy. Well done Kostya!
http://androidforums.com/threads/email-which-apps-keep-it-private.935578/
Excerpt:
NOTE: The AquaMail privacy policy statement linked below is not the usual boring legalese. Written in plain language, it's actually informative and interesting, and is the only one to mention any security testing.
AquaMail Privacy Policy
This is how it should be done! A must read!
http://www.aqua-mail.com/?page_id=1878
-
http://androidforums.com/threads/email-which-apps-keep-it-private.935578/
Yep.
The OP of that thread, Crashdamage [RIP], was on this forum too, and that thread was discussed and referenced here shortly after it was started there.
Quite a few people have found Aquamail from that thread there.
I hadn't known Crashdamage much, but from what I've learned, he made a nice contribution to Androidforums community, and I saw a thread there with very kind words from people when he wrote about what was imminently coming, and very warm posts remembering him after he passed away.
-
I hadn't known Crashdamage much, but from what I've learned, he made a nice contribution to Androidforums community, and I saw a thread there with very kind words from people when he wrote about what was imminently coming, and very warm posts remembering him after he passed away.
Thanks for that background. I read some posts in the thread you referenced. Quite a following; he did things right.
http://androidforums.com/threads/thanks-sorry-i-have-to-go.1006847
-
It's important to distinguish between authorization and authentication. Native OAuth only provides the former. Another layer (OpenID is often mentioned) is required for authentication if that functionality is required.
Unlike desktop operating systems I don't believe Android provides a native mechanism to store/secure application passwords. I believe it is up to the app to take appropriate measures.
Yes, you are correct. Sorry, I used the term loosely.
Although, it is not just me, it appears to be a frequent practice. By jargonish "OAuth authentication", people usually mean the authentication+authorization scheme that is build around OAuth.
I stand corrected.
Actually, the field has a bunch of such jargons. E.g. people call "SSL" or "SSL connection" everything that relies on x.509 certificates (aka SSL certificates), and not just SSL per se, but also TLS.
-
Being the OP I try to follow the discussion here, but it's gotten a bit to technical for me (and a bit off-topic as well ;)). Though I do appreciate how much effort you guys are taking regarding this matter! This community is really taking things seriously, nice to see.
The last month I tried out the effect of setting 'ssl accepting all', and that seemed to work good for a few weeks. Sadly, last week notifications started popping up again, and a lot too... :-\
What puzzles me is the fact that when I get a notification, the concerning account is at the same time normally accessible using the Gmail app (but this is not really very relevant like being a solution, as I'm a convinced Aquamail-fan). But I do wonder how this is possible?
Am I correct when I think the best solution for me would be to set the Gmail account to 'strict' again, combined with disabling 'SSL validation' in settings > network? Or am I proving right now that I did not understand where you guys are talking about ;)
Also, if this is to be the best solution, being a compromise as it is, I think it would indeed be very handy when this could be a per-account setting... Could not really figure out if this is being considered as a possible change in the app?
-
The last month I tried out the effect of setting 'ssl accepting all', and that seemed to work good for a few weeks. Sadly, last week notifications started popping up again, and a lot too... :-\
What puzzles me is the fact that when I get a notification, the concerning account is at the same time normally accessible using the Gmail app (but this is not really very relevant like being a solution, as I'm a convinced Aquamail-fan). But I do wonder how this is possible?
In the practical situation you are discussing (Gmail certs changing) "ssl accepting all" will not play a role in the frequency of notifications (unless, of course, there would be "bad" certs from Gmail).
Am I correct when I think the best solution for me would be to set the Gmail account to 'strict' again, combined with disabling 'SSL validation' in settings > network? Or am I proving right now that I did not understand where you guys are talking about ;)
You are correct.
Also, if this is to be the best solution, being a compromise as it is, I think it would indeed be very handy when this could be a per-account setting... Could not really figure out if this is being considered as a possible change in the app?
+11111111
-
The last month I tried out the effect of setting 'ssl accepting all', and that seemed to work good for a few weeks. Sadly, last week notifications started popping up again, and a lot too... :-\
What puzzles me is the fact that when I get a notification, the concerning account is at the same time normally accessible using the Gmail app (but this is not really very relevant like being a solution, as I'm a convinced Aquamail-fan). But I do wonder how this is possible?
In the practical situation you are discussing (Gmail certs changing) "ssl accepting all" will not play a role in the frequency of notifications (unless, of course, there would be "bad" certs from Gmail).
Am I correct when I think the best solution for me would be to set the Gmail account to 'strict' again, combined with disabling 'SSL validation' in settings > network? Or am I proving right now that I did not understand where you guys are talking about ;)
You are correct.
Also, if this is to be the best solution, being a compromise as it is, I think it would indeed be very handy when this could be a per-account setting... Could not really figure out if this is being considered as a possible change in the app?
+11111111
Fully agree on all points. :)
-
Also, if this is to be the best solution, being a compromise as it is, I think it would indeed be very handy when this could be a per-account setting... Could not really figure out if this is being considered as a possible change in the app?
+1
For the time being it could be worth to try the very latest build 1.8.2-216-dev:
https://www.aqua-mail.com/forum/index.php?topic=5472.msg32785#msg32785
https://aqua-mail.com/download/AquaMail-market-1.8.2-216-stable-166fbf35da6a.apk
This build is our release candidate not in Play yet but planned for the next week. If there are any problems, please let us know
+ Android 7, "SSL hardening" turned on -> enable "Chacha / Poly" cipher (supported by Gmail).
-
Re: The last month I tried out the effect of setting 'ssl accepting all',
This setting has no effect on the "SSL cert change" logic.
Please set it back to "SSL strict", it's safer that way.
And if the "SSL cert change" notifications are bothering you, perhaps you'd like to turn off app settings -> network -> "SSL certificate change detection".
Re: the very latest build 1.8.2-216-dev
Has absolutely no changes in "SSL cert change tracking" logic.
-
Hi! New here. Have read this through. It remains unclear to me why:
1. This only affects my Gmail account on AquaMail (I also use live.com, fastmail.com, icloud.com, my own URL on 1and1.com via Gandhi.net)
2. When I use Gmail on other clients on Android, I don't get this problem.
PS: I do appreciate the dedicated and detailed information in this thread, but a simple bulleted list from you experts setting out actions and outcomes rated low to high security risk would help the majority of AquaMail users who, like me, are simply baffled by the no doubt very accurate explanations for actions the rest of us might take.
Ta!
-
There is an FAQ on the main site...almost unbelievable, but it's true:
http(colon)//www(dot)aqua-mail(dot)com/?page_id=227
You can also go to the FAQ from the App menu (last item)
+1
Have read this FAQ: it's a really good answer for us simpletons.
It would be great to know exactly what features of a (new) Gmail SSL Certificate would mark is as being genuine.
Any advice?
PS: Comparing it to the previous one is risky if, like me, you have already accepted an older Certificate which,of course, may itself be fraudulent.
Ta!
-
Hi! New here. Have read this through. It remains unclear to me why:
1. This only affects my Gmail account on AquaMail (I also use live.com, fastmail.com, icloud.com, my own URL on 1and1.com via Gandhi.net)
2. When I use Gmail on other clients on Android, I don't get this problem.
PS: I do appreciate the dedicated and detailed information in this thread, but a simple bulleted list from you experts setting out actions and outcomes rated low to high security risk would help the majority of AquaMail users who, like me, are simply baffled by the no doubt very accurate explanations for actions the rest of us might take.
Ta!
-Gmail/Google (unnecessarily) rotates security certificates on a frequent basis
- in AquaMail navigate Settings->Network and disable (untick) "SSL certificate change detection"
- there is no meaningful security risk associated with the above action unless you frequently use WiFi in puplic locations (even then the risk is ridiculously small relative to other exposures)
-
And just to clarify:
Google rotates their certs so often these days *not* because they get compromised somehow. Not at all.
The reasons are more obscure and have to do with something called "perfect forward security", they want to make sure that
is someone's able to intercept your "encrypted" traffic (at some point in time) and then was able to decrypt it (a very difficult task right now, pretty much impossible) -- then they won't be able to leverage this *hypothetically* already decrypted data at a different point in time in the future to make decryption of new data easier.
-
The cert rotation of Google is annoying me too. I also know the CertPatrol for Firefox, just stopped using it on Palemoon today...But in these days I was annoyed by Googles rotation as well. Looking at the lease time of the certs they even rotate certs with long time validity. My first idea was they have some load sharing to different worker servers and one day I have all certs accepted, but no, they are really rotating all the time.
I still think, watching the certs is a good thing as I'm sometimes on untrusted networks and most of my email servers don't rotate that often. If you have that option to ignore cert changes in Aquamail, please make it an account option and not a global one.
-
The cert rotation of Google is annoying me too.
... If you have that option to ignore cert changes in Aquamail, please make it an account option and not a global one.
+1
-
The cert rotation of Google is annoying me too.
... If you have that option to ignore cert changes in Aquamail, please make it an account option and not a global one.
+1
I am happily adding (once again for this suggestion) my
+1
-
Re: wording:
Maybe "SSL certificate change detection"?
German translation:
SSL-Zertifikatsänderungen erkennen
Hello,
in the current version this German translation appears at the former position of "Check network connection" instead of "SSL Validation." The latter is still the translation of "SSL Validation",i.e., "SSL Prüfung".
Regards,
Zilon
-
@Zilon
Thank you!
EN
DE
Check for connection
Netzwerkverbindung prüfen
SSL certificate change detection
SSL-Zertifikatsänderungen erkennen
-
Thank you @mikeone, like this?
<string name="prefs_network_ssl_checking">SSL-Zertifikatsänderungen erkennen</string>
<string name="prefs_network_ssl_checking_summary">Benachrichtigung bei Änderung des SSL Zertifikates</string>
<string name="prefs_network_present_check">Netzwerkverbindung prüfen</string>
<string name="prefs_network_present_check_summary">Überprüfung der Netzwerkverbindung (Ausschalten bei fehlerhaften Firmwares)</string>
-
Thank you @mikeone, like this?
<string name="prefs_network_ssl_checking">SSL-Zertifikatsänderungen erkennen</string>
<string name="prefs_network_ssl_checking_summary">Benachrichtigung bei Änderung des SSL Zertifikates</string>
<string name="prefs_network_present_check">Netzwerkverbindung prüfen</string>
<string name="prefs_network_present_check_summary">Überprüfung der Netzwerkverbindung (Ausschalten bei fehlerhaften Firmwares)</string>
Yes that looks goodh