SSL certifcate doesn't seem to be checked

[paulchen]

I was wondering, because no certificate error appears when configuring an email account in aqua-mail: I am using my own domain, e.g. "example.com".

My provider offers mail services by using some subdomains under my domain, e.g. imap.example.com and smtp.example.com (@edit: but the official mail server is provided by the isp at another domain, and not via my own domain imap.example.com, so you have to enter the official mail server domainname when configuring an email client)

But the provider doesn't use a valid ssl certificate when trying to access these subdomains via ssl: normally a certificate error appears, e.g. in K9 or thunderbird. If you want to use IMAP or SMTP with a valid certificate you should use another domain (e.g. "imap.myprovider.com"), where the provider is using a "really" ssl certificate issued to the used domain.

But in aqua-mail app no error is displayed... So it seems that aqua-mail doesn't really check wheter a certificate is valid or not.

I have checked "SSL (secure)" in the account options, so it normally shouldn't accept this ssl certificates and should display an error.

This is a really unsecure behaviour. Or am I doing something wrong?!

Thanks,

paul

[StR]

There is no "SSL (secure)" option in the account settings.
Did you mean "SSL (strict checking)"? (Maybe you are back-translating from some other language?)
Indeed, that option would be responsible for strict checking of the certs validity (i.e. no self-signed certs would be allowed).

If you have that enabled, - you can also check which server names are actually configured in Aquamail for the account in question. If you relied on the automatic configuration (as opposed to "manual") and if imap.myprovider.com (or, possiblye, myprovider.com) is specified in the MX records for your domain (example.com), then, IRC, Aquamail would use imap.myprovider.com for the server.

Long-press on the account -> Account Setup -> use "Manual" to verify your account settings. (Just tap on "next" to continue without any changes.

[paulchen]

Sorry, yes, I tried to translate it back from german language to english 

You're right: I have choosen "Strict checking".

I've already checked the domain name via manual config: it is using imap.example.com by default (so my domain and not the domain name where my provider is using a "real" ceritificate) and with this setting no certificate warning is displayed.

I tried to setup it with this domain name in K9 mail and the expected warning is displayed...

I tried it with another android device: same behaviour.

Aqua mail seems not really to check the ssl certificate here... it seems to be a security issue?

[paulchen]

Find attached some Screenshots taken from K9 when trying to use the domain name (e.g. "imap.example.com", means my domain) with "wrong" ssl certificate. This warning should be displayed as well in aqua-mail, but it isn't... the certificate is accepted, that means that a man in the middle could break the encryption without any notice by the user...

[paulchen]

Are the maintainers/developers reading here in the forum or is it necessary to create a bug report somewhere? I haven't found a bug tracking system on the website. Is there any?!
Thx
paul

[Kostya Vasilyev]

Yes there are "official" people reading this forum. I'm one of them.

But please don't expect an immediate response -- this is a forum, and I (personally) read it a few times a week, not every day. There is another person from support who does too, on different days.

---

SSL (strict) means that the cert is validated against the CA's - i.e. will reject self-signed certs.

There is however *no* domain name validation - it's all too common for mail systems that offer "domain mail hosting"

- to *not* have "customer domains" in their certs, and yet
- have the mail servers under the custom domain names available

For example:

- Mail provider provider.com
- Mail servers for foo@provider.com -> imap.provider.com, smtp.provider.com
- Supports custom domains: bar@catsanddogs.com
- Mail servers for @catsanddogs: imap.catsanddogs.com aliased to imap.provider.com, smtp.catsanddogs.com aliased to smtp.catsanddogs.com
- The certificates for those servers only having the CN for *.provider.com and *not* *.catsanddogs.com

[StR]

SSL (strict) means that the cert is validated against the CA's - i.e. will reject self-signed certs.

There is however *no* domain name validation - it's all too common for mail systems that offer "domain mail hosting"

- to *not* have "customer domains" in their certs, and yet
- have the mail servers under the custom domain names available

Really?!!!
You are not kidding, are you?
I cannot believe that's the way how it is implemented by such a knowledgeable and security-conscious person like you, Kostya!
I am shocked! Please tell me that I misunderstood something here...

Here is why:

TLS certificates have two purposes:
1. Verification (of who you are talking to) and
2. Encryption of the communication.

1. The purpose of the verification is to confirm that you are indeed talking to the server with the name that you expect.
So, before issuing the certificate, CA verifies, that that domain belongs to (under control of) the requester.

In case of the "extended" TLS certificates, there could be additional verification of the entity to which the said server belongs (Bank, Governmental organization, etc.). But some CA's (including the aforementioned Let's Encrypt) do not do the latter.


For the purpose #2, a self-signed certificate is sufficient. Your communication will not be accessible for others, but you would not know who you are talking to (unless you received that site's certificate via trusted channels, and hence trust it).
So, essentially, when a user disables "strict checking" in Aquamail, he/she essentially says: "I don't really care who I am communicating with, as long as nobody else can hear it, and hopefully it will be my e-mail, and it will not be read by a MITM."

When that user wants to have certainty about the communication end-point, but he/she cannot (or shouldn't) use a certificate issued by a chain leading to a trusted CA, - the choice is to import the self-signed "root" certificate of that "self-CA" into the local device's database, thus adding it to the [locally] trusted CAs.
Sometimes that is done with privately issued certs (by a company, for access to the company resources).


Now, in a situation such as that discussed by the OP, essentially NO verification is happening. So, the situation is not better than in case of the self-signed certificate + "strict check" option disabled. The situation is somewhat improved if the user enables "track certificate change" option, which is disabled by default, IIRC. In that case, the situation is getting close to that when a user imports a self-signed CA cert... but only until the server certificate changes. Then, all bets are off.

So, the present "strict SSL check" option in Aquamail is grossly misleading.
Here is just one scenario of the MITM: A perpetrator takes (through a hack/exploit/social engineering/..) the SSL certificate of the server domain.com, and installs it on his evildomain.com, and then through traffic interception/diversion (either via traffic diversion or via DNS cache poisoning, or several other schemes), diverts Aquamail connection to evildomain.com. You are sure that you are connecting to domain.com (because you enabled strict SSL checking), and submit your login-password credentials. Your account is compromised.

I know several users whose accounts were compromised via traffic interception/diversion (not via Aquamail).

I understand that you are simplifying your life by not hearing complaints from the users who are using providers in the way you described. But... No!... It is a BIG BUT

You are subjecting all other users (who are doing everything right, using the right configuration with the correct provider, paying for the certificate for their domain with the correct CN or alternative names) to the danger of having their accounts compromised.
You are negating the very purpose why they obtained a proper certificate signed by a trusted CA.

Remember that thread on AndroidForums by the late Crashdamage? I'd say that most of those advantages about privacy and security highlighted there are negated by this behavior of Aquamail.

In the situation you described, those users of the "el-cheapo" providers should use imap.provider.com and smtp.provider.com, not imap.catsanddogs.com, if they didn't pay for
the certs for their domain. (After all, it is only once that they need to configure it manually.)
They chose a cheap option, and they are inconvenienced. And yes, sorry, you will be inconvenienced too, because they will be surprised why automatically chosen server is not working for them. But all other thorough users will not be subjected to the risk of being compromised.
(Alternatively, they can disable "Strict checking" in Aquamail and test their luck.)

I think this hidden security hole must be fixed ASAP.
(It is so significant that I'd be forced to give up the legacy version that has "reflow-after-zoom", as well as a few features that don't exist in the later versions.)

The correct behavior would be if this functionality (not checking against the server name) was happening when "Strict checking" is disabled, whereas Aquamail would stop connecting and throw an error message when "Strict checking" is enabled, and if the server name doesn't match.

[Kostya Vasilyev]

Really?!!!
You are not kidding, are you?
I cannot believe that's the way how it is implemented by such a knowledgeable and security-conscious person like you, Kostya!
I am shocked! Please tell me that I misunderstood something here...

No I'm not kidding.

There are lot of setups out there like I described above - which use "custom domain" mail server DNS names that point to the "real" server names (a CNAME, let's say) *and* the "real" server's certificates that *do not* include the "custom" domains in their CN"s.

Doing "browser compatible" (let's say) CN / domain name validation would make it impossible to add such accounts without stopping and requiring the user to make a decision.

And the average user knows about as much about CN's, DNS, and certificates -- as I know about microbiology (which is absolutely nothing, to be clear).

---

For the record - for OAUTH type accounts if "SSL hardening" enabled, then there *is* CN validation (the OAUTH code has to know "something" about the services we support - so it also provides the list of expected CN names).

[paulchen]

Doing "browser compatible" (let's say) CN / domain name validation would make it impossible to add such accounts without stopping and requiring the user to make a decision.

And the average user knows about as much about CN's, DNS, and certificates -- as I know about microbiology (which is absolutely nothing, to be clear).

So, it would be better to disable every security check everywhere, because it would always be some kind of  uncomfortable for the user... No, I am kidding.

It is a great security bug in my opinion and you should fix it. It is very important to check, if the server you communicate to, is the server you mean. And for that is a certificate used and aqua-mail is ignoring this without informing the user. And that's not ok.

Every other mail client that I know is checking the CN (as it should be!) and bring's up a warning to the user, when the used certificate is not valid for the domain you are trying to establish your ssl connection. The user has normally the choice: "ok, I accept the certificate" or he can change the configuration manually to get it work. That's comfortable enough, even for the uninformed user.

Aqua-mail tries to guess the valid server names for IMAP/SMTP, but it doesn't do a good job, because it guess not right. It is not mandatory, that the mailserver names are always "imap.catsanddoggs.com" and "smtp.catsanddoggs.com".

I agree in all points with StR. It should be fixed as soon as possible.

Thanks,
paul

[StR]

There are lot of setups out there like I described above - which use "custom domain" mail server DNS names that point to the "real" server names (a CNAME, let's say) *and* the "real" server's certificates that *do not* include the "custom" domains in their CN"s.

Doing "browser compatible" (let's say) CN / domain name validation would make it impossible to add such accounts without stopping and requiring the user to make a decision.

Kostya, sorry, but all those arguments are about convenience of some users and "automagic" behavior of Aquamail.
The price for that is broken trust for everybody else.
One of the two functions of an SSL/TLS connection is broken in this implementation where it is expected (by any knowledgeable user, and must be provided to all users). Period.

This is notan inconvenience. It is not even an accessibility issue like "Reflow-after-zoom" (the aspect you consistently ignored). Ask any person knowledgeable about security connection. It is a security vulnerability.
It is as serious as it gets.

Most of my day today, I am in shock, after learning about it. I can hardly believe it's real:
I've never expected such a gaping hole in Aquamail created deliberately. But even worse than that, I've never expected that you wouldn't understand the severity of it and its implications.

You know, I've been a big fan and proponent of Aquamail for over 3 years. For sure tens (that I know of), likely hundreds of people started using it after hearing about it from me. I am thinking now that if I had known about this security hole, that would not have happened.

If this issue is not fixed, I will be forced to make sure that this vulnerability is well known. In all honesty, I would rather prefer (and sincerely hope) that you'd realize all the depth of this problem and have it fixed.
I already feel very sad about this situation, and it would get worse.
(Ghm... it sounds like a threat, which I don't like. But I don't have time now to phrase it differently.)

Please, read my suggestion in the previous post: this can be "fixed" relatively easily, without breaking it much for those users who would benefit from this lack of verification: just shift this behavior under "non-strict" checking (which it is!).
(Even that is questionable in my books, for the reasons explained in the previous post. But at least there will be a way to have fully functioning secure connection un-broken for those who expect it, and for everybody who deserves it).

If it is "strict SSL checking", it must do name (CN and aliases) checking.


PS. @paulchen: Paul, I greatly appreciate that you've brought up to light this "zero-day" security problem in Aquamail.

[Kostya Vasilyev]

You're right, it is a security issue.

My thinking was -

- The "more knowledgeable" users would enable "ssl cert tracking" and examine the certs if they so desire

- But assuming that every (or even most) users are in this category would be naive

And there is evidence for it too: the infamous "app is broken and doesn't work with Gmail since latest update" AKA "Gmail SSL cert changes".

People forget that they've enabled a setting, don't see a connection to the "error" message, can't check the FAQ (we've got links to help / forum / FAQ on every screen!!!), and instead - "app is broken, plz fix now".

-- That being said:

We could implement cert CN checks, and show some sort of popup / message during account setup if there is no match, and also have a capability to do this if the "cert has no CN for server name" shows up later (not during setup).

We could deal with self-signed certs the same way: right now they require the user to tweak the account's server settings and choose "SSL (accept any)" instead of "SSL (strict)".

The "track SSL cert changes" feature would change too, to combine better the CN / self signed logic.

Re: your proposal for moving this under "accept any":

... and to do server name / CN validation for "strict":

That would be an easy way to do it with minimal code changes and minimal impact (hopefully) on users.

But those are really different things: 1) CA chain of trust 2) CN / server name validation and 3) expiration date / time (also happens).

If we did it with a prompt - which is obviously more work and would take longer - we'd also need to be careful when saving a "user accepted" certificate because:

If a cert is "accepted" from a prompt about "CN / server name", and later expires (let's say) - we'd still want to flag the expiration as an error, to be accepted again, as separate consent.

Same with "self signed" -> "expiration".

[Kostya Vasilyev]

@StR -

- thanks for the idea of only doing CN checking for "SSL / TLS (strict)".

This is a good change "for now", done and posted here:

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

[StR]

Kostya: First of all, I am glad that you realized the severity of the issue.

Second, - just in case, - I assume Aquamail is now checking for "Subject Alternative Name" as well, not just CN. Right?

I am glad to hear that you've already "shifted" that lack of complete checking under "accept-any" option, and I am even more glad to hear that you are considering doing a more comprehensive rethinking the part dealing with the certificates.
In the interim, - very briefly: In addition to what you are adding to the list of checks (expiration), is the CRL checked as well (either by Auqamail or by the Android built-in mechanism that you are relying on)?


I have some comments and thoughts but I don't have much time at the moment. So, I'll try to respond with those a bit later.

PS. Yesterday, while trying to post my response from the road (from a phone), I discovered that I was logged out from the forum (and that resulted in the loss of the text I wrote). This morning I've found that my desktop's browsers was also logged out. I hope that was a result of your server maintenance as opposed to something unknown/malicious.

[Kostya Vasilyev]

Re: Second, - just in case, - I assume Aquamail is now checking for "Subject Alternative Name" as well, not just CN. Right?

Of course. And wildcards too.

The actual code doing the checking is in the Apache http libraries and was already used in Aqua for EWS.

http://www.atetric.com/atetric/javadoc/org.apache.httpcomponents/httpclient/4.5/src-html/org/apache/http/conn/ssl/AbstractVerifier.html

Not same exact version (we're using a snapshot of 4.3, fixed up and ported to Android) but it looks close enough.

[paulchen]

Thanks for implementing. Is there any idea when the fix will be available for the user and published via play store?

By the way: I've noticed that on my tablet there is a button when the manual configuration is finished where the user can view the SSL certificate of the server. On my smartphone this button is'nt available in aqua-mail... Is there any reason for this? Or is it maybe missing in the smartphone view/activity of the app?

@edit find attached two screenshots from tablet and smartphone