Author Topic: Version 1.12.0-587-dev - "work in progress", not in Google Play  (Read 6757 times)

Kostya Vasilyev

  • Hero Member
  • *****
  • Posts: 12740
Version 1.12.0-587-dev - "work in progress", not in Google Play
« on: September 03, 2017, 05:04:08 pm »
https://www.aqua-mail.com/download/AquaMail-market-1.12.0-587-dev-ad1c7bd8b2ed.apk

---

+ Added a special case for Gmail in "track SSL cert changes" code.

Lately, Google seems to be changing Gmail's certs even more often than once a week. This can be annoying.

The code recognizes certs issued by "Google Internet Authority G2" (based on the hash / signature) and silently accepts them. It does not make the app any less secure.

---

+ Добавили спец обработку Gmail при включенном "отслеживании SSL сертфикатов".

В последнее время Google меняют сертификаты Gmail даже более часто чем раз в неделю. Это вызывает неудобства.

Программа распознаёт сертификаты выданные  "Google Internet Authority G2" (на основе хеша / подписи) и сразу принимает их. Менее безопасной программа от этого не стала.
« Last Edit: September 08, 2017, 08:22:49 pm by Kostya Vasilyev, Aqua Mail »
Creating debug logs for diagnostics: https://www.aqua-mail.com/troubleshooting/

The official FAQ: https://www.aqua-mail.com/faq/

Лог-файлы для диагностики: https://www.aqua-mail.com/ru/troubleshooting/

Вопросы и ответы: https://www.aqua-mail.com/ru/faq/

StR

  • Hero Member
  • *****
  • Posts: 1558
Re: Version 1.12.0-587-dev - "work in progress", not in Google Play
« Reply #1 on: September 04, 2017, 09:46:53 am »
 Kostya,

Two thoughts/questions on the subject.
1. I remember you've made a previous change a few months back, -- one that was supposed to improve dealing with the frequent cert rotation.
My question with respect to that: with earlier versions, multiple Gmail accounts would individually require confirming the same new certificate. Was that behavior changed in the earlier change?
(I.e. with other, non Gmail servers and multiple accounts, - would the change of certs have to be confirmed for different accounts separately?)

2. As a reminder, - there was a suggestion from several different people to make the option of "warn about cert change" per account.


PS. I am not sure if I like this recent change. On one hand, I like the idea, and that it is somewhat better than no tracking of the cert change. On another hand, if that totally and unconditionally removes notification of Gmail's certs as long as the name matches, - then it might not be what the most security conscious people want.

Personally, - I  look at the Gmail certs change more carefully when I am seeing that in "shady" areas (where rogue Wi-Fi spots might be installed).
So, my question is: can a user still have an option to be warned about the cert change even for Gmail?

Kostya Vasilyev

  • Hero Member
  • *****
  • Posts: 12740
Re: Version 1.12.0-587-dev - "work in progress", not in Google Play
« Reply #2 on: September 04, 2017, 01:16:09 pm »
Re: one that was supposed to improve dealing with the frequent cert rotation

Was longer than that, but yes that change is still there.

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).

This new change just adds a special case for Google's certs.

Re: make the option of "warn about cert change" per account

Won't work. I'll explain below.

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 )

---

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.

Creating debug logs for diagnostics: https://www.aqua-mail.com/troubleshooting/

The official FAQ: https://www.aqua-mail.com/faq/

Лог-файлы для диагностики: https://www.aqua-mail.com/ru/troubleshooting/

Вопросы и ответы: https://www.aqua-mail.com/ru/faq/

StR

  • Hero Member
  • *****
  • Posts: 1558
Re: Version 1.12.0-587-dev - "work in progress", not in Google Play
« Reply #3 on: September 07, 2017, 05:33:25 pm »
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.

Kostya Vasilyev

  • Hero Member
  • *****
  • Posts: 12740
Re: Version 1.12.0-587-dev - "work in progress", not in Google Play
« Reply #4 on: September 07, 2017, 05:59:42 pm »
Quote
if I accepted a new cert in one account, and another account has the same server and port, - it would be considered accepted.

When I originally wrote this, I thought it'd be useful to track this per-account (per endpoint: "server name + port").

Maybe it's not as useful as I'd thought - but right now I just made one change for one specific issue, it wasn't my intent to go back and re-do the whole feature.

Quote
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.

1 - The code looks at the issuer cert's hash / signature not name, and specifically checks for the (current) signature/hash of Google's issuer cert.

2 - The issuer of Gmail certificates is a certificate that Google controls and (hopefully) nobody outside Google can use it.

I mean just do your "homework" please, run openssl x509 -text -noout or something.

Google has info on their issuer here:

https://pki.google.com/

which clearly says that "all google certs are issued by this one issuer".

Or putting it differently - Gmail certs are *not* issued by Comodo or Verisign or WeSign or whatever.

Quote
There have been known cases like that

I don't think in these cases the cert(s) had matching (to the real thing) hash / signature, do you?

Quote
Let's Encrypt's certificates are rotating them about every 2 months

True, and I don't see a good solution for Let's Encrypt.

Which is funny - "let's try to have better security by re-issuing certs often" -> ends up being -> "worse security because you can't conveniently detect / prevent MITM anymore".
Creating debug logs for diagnostics: https://www.aqua-mail.com/troubleshooting/

The official FAQ: https://www.aqua-mail.com/faq/

Лог-файлы для диагностики: https://www.aqua-mail.com/ru/troubleshooting/

Вопросы и ответы: https://www.aqua-mail.com/ru/faq/

StR

  • Hero Member
  • *****
  • Posts: 1558
Re: Version 1.12.0-587-dev - "work in progress", not in Google Play
« Reply #5 on: September 07, 2017, 08:02:43 pm »
Kostya, thank you for the detailed response and clarification!

Quote
if I accepted a new cert in one account, and another account has the same server and port, - it would be considered accepted.

When I originally wrote this, I thought it'd be useful to track this per-account (per endpoint: "server name + port").

Maybe it's not as useful as I'd thought - but right now I just made one change for one specific issue, it wasn't my intent to go back and re-do the whole feature.

This is a second change related to this functionality in the recent past (~ 0.5 year). I suspect you might be making some more changes in the near future. So, when and if you'll be working on something related again, please keep this suggestion in mind.


Quote
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.

1 - The code looks at the issuer cert's hash / signature not name, and specifically checks for the (current) signature/hash of Google's issuer cert.

2 - The issuer of Gmail certificates is a certificate that Google controls and (hopefully) nobody outside Google can use it.

I mean just do your "homework" please, run openssl x509 -text -noout or something.

Google has info on their issuer here:

https://pki.google.com/

which clearly says that "all google certs are issued by this one issuer".

Or putting it differently - Gmail certs are *not* issued by Comodo or Verisign or WeSign or whatever.

I see, I misunderstood which hash/information you were checking in this recent update.
The way I understand it now, after your clarification, - you (Aquamail) are already checking for the hash that identifies the CA issuing the certificate.
My apology for the misunderstanding and the unnecessary noise about that aspect.

A followup question that I have to that: What would happen if a Gmail cert changes, and Aquamail detects a change in the hash/signature of the CA? Does it effectively behave as before, i.e. offering the same "comparison" page, and giving an option to accept that manually? Or what?


Based on your clarification and my better understanding of the recent change, I am still proposing:
Quote
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.
5. Consider if CAA query is useful/feasible (see the footnote {^} below).


Quote
Let's Encrypt's certificates are rotating them about every 2 months

True, and I don't see a good solution for Let's Encrypt.

Which is funny - "let's try to have better security by re-issuing certs often" -> ends up being -> "worse security because you can't conveniently detect / prevent MITM anymore".

I have been thinking about this issue (and have been discussing this in the presentation I referred to). I was confused by this (and Google's) model at first, but then I agreed that it has an advantage.
Let me share my thoughts on that here.

There are two separate issues that people are trying to deal with: 1. MITM attack and 2. Forward secrecy.
The current state of things (implementation of most software relying on TLS certificates, with very few exceptions) is such that almost all software (with exceptions that can be counted on one hand, including Aquamail) does not track certificate change (from one session to another). This includes web-browsers, e-mail clients, etc. The exceptions are Aquamail, Claws Mail, SSH clients, and a few (I found 2-4 in various states of realization) 3rd-party-based projects helping with pinning/caching certs (including 2 web-browser plugins with very limited deployment/availability).
So, the detection of the MITM attack (1) by tracking the certificate change is mostly nonexistent.{^}

Hence, by drastically improving the issue related to (2) by frequent replacement of the certs {#}, we are not loosing much for the issue (1).




------------------
{^}: There are solutions that help detecting a MITM attack related to certificates:
The most "targeted" at the issue in question is via DNS "CAA" record, e.g.
                CAA 0 issue "letsencrypt.org"
That's based on RFC 6844. You can see a better description of it e.g. here https://support.dnsimple.com/articles/caa-record/ .
Obviously, it is not perfect and it is prone to DNS injection, but, as any security measure, it is better than nothing.

Actually, you might consider if this could be helpful in verifying certificate issuer when the certificate changes (as I proposed in the previous post) -- for servers other then Gmail.

{#}:
For reference, a while ago, I found this information (Microsoft blogpost referencing RSA research, ca.2009):
Key length and cert validity:
1024:  < 6-12 months
2048:  < 2 years
4096:  < 16 years
I don't know if that projection/recommendation has been updated since that.




Kostya Vasilyev

  • Hero Member
  • *****
  • Posts: 12740
Re: Version 1.12.0-587-dev - "work in progress", not in Google Play
« Reply #6 on: September 07, 2017, 09:40:55 pm »
Quote
I see, I misunderstood which hash/information you were checking in this recent update.
The way I understand it now, after your clarification, - you (Aquamail) are already checking for the hash that identifies the CA issuing the certificate.
My apology for the misunderstanding and the unnecessary noise about that aspect.

A followup question that I have to that: What would happen if a Gmail cert changes, and Aquamail detects a change in the hash/signature of the CA? Does it effectively behave as before, i.e. offering the same "comparison" page, and giving an option to accept that manually? Or what?

Not the CA.

Google has a special "issuer" certificate that they use for (Gmail at least) and looks like all Google certs.

This is explained at the link I posted above.

[ well known CA: GeoTrust Global CA ] -> [ Google G2 Internet Cert ] -> [ Gmail certs ]

Aqua recognizes the issuer cert - the Google G2 Internet Cert - and silently accepts any "end" certificates coming from this special issuer.

Nobody outside of Google has access to the "Google G2" certificate (or at least I hope this is the case) and cannot issue certs "from" this cert, and therefore, the above is safe.

---

Compare to Office 365 for example:

[ DigiCert Cloud Services CA-1 ] -> [ outlook.office365.com ]

The issuer - DigiCert Cloud Services CA-1 - is not specific to Office 365 or Microsoft, so we can't do this kind of trick.

Quote
What would happen if a Gmail cert changes, and Aquamail detects a change in the hash/signature of the CA? Does it effectively behave as before, i.e. offering the same "comparison" page, and giving an option to accept that manually? Or what?

As I wrote in the original post, the app now silently accepts certificates issued by "Google G2 Internet Cert" (and this cert is recognized by its hash / signature).

Getting rid of the change "error" for Gmail was the point.

Now what will happen when the G2 certificate changes?

The app won't anymore recognize Gmail certs as being special (since it won't recognize the issuer cert), and users will start getting the old "ssl cert changed" messages, until we update the app to include hash for the new "Google G2" cert.

---

Now something that makes it worse for the moment for Gmail is --

-- the IMAP and the SMTP server certificates are different.

So someone may accept the IMAP cert and still get "the dreaded error" a bit later when sending. The change described here avoids this too.

Creating debug logs for diagnostics: https://www.aqua-mail.com/troubleshooting/

The official FAQ: https://www.aqua-mail.com/faq/

Лог-файлы для диагностики: https://www.aqua-mail.com/ru/troubleshooting/

Вопросы и ответы: https://www.aqua-mail.com/ru/faq/

Kostya Vasilyev

  • Hero Member
  • *****
  • Posts: 12740
Re: Version 1.12.0-587-dev - "work in progress", not in Google Play
« Reply #7 on: September 07, 2017, 09:45:53 pm »
Tangentially related to the "different certs for imap.gmail.com vs. smtp.gmail.com".

This is from the cert for plus.google.com, LOL:

Quote
X509v3 Subject Alternative Name:
                DNS:google.com, DNS:*.2mdn.net, DNS:*.android.com, DNS:*.appengine.google.com, DNS:*.au.doubleclick.net, DNS:*.cc-dt.com, DNS:*.cloud.google.com, DNS:*.db833953.google.cn, DNS:*.de.doubleclick.net, DNS:*.doubleclick.com, DNS:*.doubleclick.net, DNS:*.fls.doubleclick.net, DNS:*.fr.doubleclick.net, DNS:*.g.co, DNS:*.gcp.gvt2.com, DNS:*.google-analytics.com, DNS:*.google.ac, DNS:*.google.ad, DNS:*.google.ae, DNS:*.google.af, DNS:*.google.ag, DNS:*.google.ai, DNS:*.google.al, DNS:*.google.am, DNS:*.google.as, DNS:*.google.at, DNS:*.google.az, DNS:*.google.ba, DNS:*.google.be, DNS:*.google.bf, DNS:*.google.bg, DNS:*.google.bi, DNS:*.google.bj, DNS:*.google.bs, DNS:*.google.bt, DNS:*.google.by, DNS:*.google.ca, DNS:*.google.cat, DNS:*.google.cc, DNS:*.google.cd, DNS:*.google.cf, DNS:*.google.cg, DNS:*.google.ch, DNS:*.google.ci, DNS:*.google.cl, DNS:*.google.cm, DNS:*.google.cn, DNS:*.google.co.ao, DNS:*.google.co.bw, DNS:*.google.co.ck, DNS:*.google.co.cr, DNS:*.google.co.hu, DNS:*.google.co.id, DNS:*.google.co.il, DNS:*.google.co.im, DNS:*.google.co.in, DNS:*.google.co.je, DNS:*.google.co.jp, DNS:*.google.co.ke, DNS:*.google.co.kr, DNS:*.google.co.ls, DNS:*.google.co.ma, DNS:*.google.co.mz, DNS:*.google.co.nz, DNS:*.google.co.th, DNS:*.google.co.tz, DNS:*.google.co.ug, DNS:*.google.co.uk, DNS:*.google.co.uz, DNS:*.google.co.ve, DNS:*.google.co.vi, DNS:*.google.co.za, DNS:*.google.co.zm, DNS:*.google.co.zw, DNS:*.google.com, DNS:*.google.com.af, DNS:*.google.com.ag, DNS:*.google.com.ai, DNS:*.google.com.ar, DNS:*.google.com.au, DNS:*.google.com.bd, DNS:*.google.com.bh, DNS:*.google.com.bn, DNS:*.google.com.bo, DNS:*.google.com.br, DNS:*.google.com.by, DNS:*.google.com.bz, DNS:*.google.com.cn, DNS:*.google.com.co, DNS:*.google.com.cu, DNS:*.google.com.cy, DNS:*.google.com.do, DNS:*.google.com.ec, DNS:*.google.com.eg, DNS:*.google.com.et, DNS:*.google.com.fj, DNS:*.google.com.ge, DNS:*.google.com.gh, DNS:*.google.com.gi, DNS:*.google.com.gr, DNS:*.google.com.gt, DNS:*.google.com.hk, DNS:*.google.com.iq, DNS:*.google.com.jm, DNS:*.google.com.jo, DNS:*.google.com.kh, DNS:*.google.com.kw, DNS:*.google.com.lb, DNS:*.google.com.ly, DNS:*.google.com.mm, DNS:*.google.com.mt, DNS:*.google.com.mx, DNS:*.google.com.my, DNS:*.google.com.na, DNS:*.google.com.nf, DNS:*.google.com.ng, DNS:*.google.com.ni, DNS:*.google.com.np, DNS:*.google.com.nr, DNS:*.google.com.om, DNS:*.google.com.pa, DNS:*.google.com.pe, DNS:*.google.com.pg, DNS:*.google.com.ph, DNS:*.google.com.pk, DNS:*.google.com.pl, DNS:*.google.com.pr, DNS:*.google.com.py, DNS:*.google.com.qa, DNS:*.google.com.ru, DNS:*.google.com.sa, DNS:*.google.com.sb, DNS:*.google.com.sg, DNS:*.google.com.sl, DNS:*.google.com.sv, DNS:*.google.com.tj, DNS:*.google.com.tn, DNS:*.google.com.tr, DNS:*.google.com.tw, DNS:*.google.com.ua, DNS:*.google.com.uy, DNS:*.google.com.vc, DNS:*.google.com.ve, DNS:*.google.com.vn, DNS:*.google.cv, DNS:*.google.cz, DNS:*.google.de, DNS:*.google.dj, DNS:*.google.dk, DNS:*.google.dm, DNS:*.google.dz, DNS:*.google.ee, DNS:*.google.es, DNS:*.google.eus, DNS:*.google.fi, DNS:*.google.fm, DNS:*.google.fr, DNS:*.google.frl, DNS:*.google.ga, DNS:*.google.gal, DNS:*.google.ge, DNS:*.google.gg, DNS:*.google.gl, DNS:*.google.gm, DNS:*.google.gp, DNS:*.google.gr, DNS:*.google.gy, DNS:*.google.hk, DNS:*.google.hn, DNS:*.google.hr, DNS:*.google.ht, DNS:*.google.hu, DNS:*.google.ie, DNS:*.google.im, DNS:*.google.in, DNS:*.google.info, DNS:*.google.iq, DNS:*.google.ir, DNS:*.google.is, DNS:*.google.it, DNS:*.google.it.ao, DNS:*.google.je, DNS:*.google.jo, DNS:*.google.jobs, DNS:*.google.jp, DNS:*.google.kg, DNS:*.google.ki, DNS:*.google.kz, DNS:*.google.la, DNS:*.google.li, DNS:*.google.lk, DNS:*.google.lt, DNS:*.google.lu, DNS:*.google.lv, DNS:*.google.md, DNS:*.google.me, DNS:*.google.mg, DNS:*.google.mk, DNS:*.google.ml, DNS:*.google.mn, DNS:*.google.ms, DNS:*.google.mu, DNS:*.google.mv, DNS:*.google.mw, DNS:*.google.ne, DNS:*.google.ne.jp, DNS:*.google.net, DNS:*.google.ng, DNS:*.google.nl, DNS:*.google.no, DNS:*.google.nr, DNS:*.google.nu, DNS:*.google.off.ai, DNS:*.google.pk, DNS:*.google.pl, DNS:*.google.pn, DNS:*.google.ps, DNS:*.google.pt, DNS:*.google.ro, DNS:*.google.rs, DNS:*.google.ru, DNS:*.google.rw, DNS:*.google.sc, DNS:*.google.se, DNS:*.google.sh, DNS:*.google.si, DNS:*.google.sk, DNS:*.google.sm, DNS:*.google.sn, DNS:*.google.so, DNS:*.google.sr, DNS:*.google.st, DNS:*.google.td, DNS:*.google.tel, DNS:*.google.tg, DNS:*.google.tk, DNS:*.google.tl, DNS:*.google.tm, DNS:*.google.tn, DNS:*.google.to, DNS:*.google.tt, DNS:*.google.ua, DNS:*.google.us, DNS:*.google.uz, DNS:*.google.vg, DNS:*.google.vu, DNS:*.google.ws, DNS:*.googleadapis.com, DNS:*.googleadsserving.cn, DNS:*.googleapis.cn, DNS:*.googlecommerce.com, DNS:*.googleusercontent.cn, DNS:*.googlevideo.com, DNS:*.gstatic.cn, DNS:*.gstatic.com, DNS:*.gvt1.com, DNS:*.gvt2.com, DNS:*.jp.doubleclick.net, DNS:*.metric.gstatic.com, DNS:*.uk.doubleclick.net, DNS:*.urchin.com, DNS:*.url.google.com, DNS:*.youtube-nocookie.com, DNS:*.youtube.com, DNS:*.youtubeeducation.com, DNS:*.yt.be, DNS:*.ytimg.com, DNS:ad.mo.doubleclick.net, DNS:android.clients.google.com, DNS:android.com, DNS:developer.android.google.cn, DNS:developers.android.google.cn, DNS:doubleclick.com, DNS:doubleclick.net, DNS:g.co, DNS:goo.gl, DNS:google-analytics.com, DNS:google.ac, DNS:google.ad, DNS:google.ae, DNS:google.af, DNS:google.ag, DNS:google.ai, DNS:google.al, DNS:google.am, DNS:google.as, DNS:google.at, DNS:google.az, DNS:google.ba, DNS:google.be, DNS:google.bf, DNS:google.bg, DNS:google.bi, DNS:google.bj, DNS:google.bs, DNS:google.bt, DNS:google.by, DNS:google.ca, DNS:google.cat, DNS:google.cc, DNS:google.cd, DNS:google.cf, DNS:google.cg, DNS:google.ch, DNS:google.ci, DNS:google.cl, DNS:google.cm, DNS:google.cn, DNS:google.co.ao, DNS:google.co.bw, DNS:google.co.ck, DNS:google.co.cr, DNS:google.co.hu, DNS:google.co.id, DNS:google.co.il, DNS:google.co.im, DNS:google.co.in, DNS:google.co.je, DNS:google.co.jp, DNS:google.co.ke, DNS:google.co.kr, DNS:google.co.ls, DNS:google.co.ma, DNS:google.co.mz, DNS:google.co.nz, DNS:google.co.th, DNS:google.co.tz, DNS:google.co.ug, DNS:google.co.uk, DNS:google.co.uz, DNS:google.co.ve, DNS:google.co.vi, DNS:google.co.za, DNS:google.co.zm, DNS:google.co.zw, DNS:google.com.af, DNS:google.com.ag, DNS:google.com.ai, DNS:google.com.ar, DNS:google.com.au, DNS:google.com.bd, DNS:google.com.bh, DNS:google.com.bn, DNS:google.com.bo, DNS:google.com.br, DNS:google.com.by, DNS:google.com.bz, DNS:google.com.cn, DNS:google.com.co, DNS:google.com.cu, DNS:google.com.cy, DNS:google.com.do, DNS:google.com.ec, DNS:google.com.eg, DNS:google.com.et, DNS:google.com.fj, DNS:google.com.ge, DNS:google.com.gh, DNS:google.com.gi, DNS:google.com.gr, DNS:google.com.gt, DNS:google.com.hk, DNS:google.com.iq, DNS:google.com.jm, DNS:google.com.jo, DNS:google.com.kh, DNS:google.com.kw, DNS:google.com.lb, DNS:google.com.ly, DNS:google.com.mm, DNS:google.com.mt, DNS:google.com.mx, DNS:google.com.my, DNS:google.com.na, DNS:google.com.nf, DNS:google.com.ng, DNS:google.com.ni, DNS:google.com.np, DNS:google.com.nr, DNS:google.com.om, DNS:google.com.pa, DNS:google.com.pe, DNS:google.com.pg, DNS:google.com.ph, DNS:google.com.pk, DNS:google.com.pl, DNS:google.com.pr, DNS:google.com.py, DNS:google.com.qa, DNS:google.com.ru, DNS:google.com.sa, DNS:google.com.sb, DNS:google.com.sg, DNS:google.com.sl, DNS:google.com.sv, DNS:google.com.tj, DNS:google.com.tn, DNS:google.com.tr, DNS:google.com.tw, DNS:google.com.ua, DNS:google.com.uy, DNS:google.com.vc, DNS:google.com.ve, DNS:google.com.vn, DNS:google.cv, DNS:google.cz, DNS:google.de, DNS:google.dj, DNS:google.dk, DNS:google.dm, DNS:google.dz, DNS:google.ee, DNS:google.es, DNS:google.eus, DNS:google.fi, DNS:google.fm, DNS:google.fr, DNS:google.frl, DNS:google.ga, DNS:google.gal, DNS:google.ge, DNS:google.gg, DNS:google.gl, DNS:google.gm, DNS:google.gp, DNS:google.gr, DNS:google.gy, DNS:google.hk, DNS:google.hn, DNS:google.hr, DNS:google.ht, DNS:google.hu, DNS:google.ie, DNS:google.im, DNS:google.in, DNS:google.info, DNS:google.iq, DNS:google.ir, DNS:google.is, DNS:google.it, DNS:google.it.ao, DNS:google.je, DNS:google.jo, DNS:google.jobs, DNS:google.jp, DNS:google.kg, DNS:google.ki, DNS:google.kz, DNS:google.la, DNS:google.li, DNS:google.lk, DNS:google.lt, DNS:google.lu, DNS:google.lv, DNS:google.md, DNS:google.me, DNS:google.mg, DNS:google.mk, DNS:google.ml, DNS:google.mn, DNS:google.ms, DNS:google.mu, DNS:google.mv, DNS:google.mw, DNS:google.ne, DNS:google.ne.jp, DNS:google.net, DNS:google.ng, DNS:google.nl, DNS:google.no, DNS:google.nr, DNS:google.nu, DNS:google.off.ai, DNS:google.pk, DNS:google.pl, DNS:google.pn, DNS:google.ps, DNS:google.pt, DNS:google.ro, DNS:google.rs, DNS:google.ru, DNS:google.rw, DNS:google.sc, DNS:google.se, DNS:google.sh, DNS:google.si, DNS:google.sk, DNS:google.sm, DNS:google.sn, DNS:google.so, DNS:google.sr, DNS:google.st, DNS:google.td, DNS:google.tel, DNS:google.tg, DNS:google.tk, DNS:google.tl, DNS:google.tm, DNS:google.tn, DNS:google.to, DNS:google.tt, DNS:google.ua, DNS:google.us, DNS:google.uz, DNS:google.vg, DNS:google.vu, DNS:google.ws, DNS:googlecommerce.com, DNS:gstatic.com, DNS:source.android.google.cn, DNS:urchin.com, DNS:www.goo.gl, DNS:youtu.be, DNS:youtube.com, DNS:youtubeeducation.com, DNS:yt.be

Gmail is not like that: there are distinct certs for imap.gmail.com / smtp.gmail.com and also for their *.googlemail.com siblings.
Creating debug logs for diagnostics: https://www.aqua-mail.com/troubleshooting/

The official FAQ: https://www.aqua-mail.com/faq/

Лог-файлы для диагностики: https://www.aqua-mail.com/ru/troubleshooting/

Вопросы и ответы: https://www.aqua-mail.com/ru/faq/

Kostya Vasilyev

  • Hero Member
  • *****
  • Posts: 12740
Re: Version 1.12.0-587-dev - "work in progress", not in Google Play
« Reply #8 on: September 07, 2017, 09:51:48 pm »
Re: DNS CAA records

Yes I've heard about them.

Can't create one for my web site (Linode), and they don't seem very widely used yet.

It does help somewhat - but only severely limiting what options are available to the malicious party for creating his/her MITM cert.

But it does not directly prevent such party from doing their bad deed.

Wonder why there isn't a "side channel" for validating the "expected" cert directly? Say some other DNS record?

Creating debug logs for diagnostics: https://www.aqua-mail.com/troubleshooting/

The official FAQ: https://www.aqua-mail.com/faq/

Лог-файлы для диагностики: https://www.aqua-mail.com/ru/troubleshooting/

Вопросы и ответы: https://www.aqua-mail.com/ru/faq/

StR

  • Hero Member
  • *****
  • Posts: 1558
Re: Version 1.12.0-587-dev - "work in progress", not in Google Play
« Reply #9 on: September 08, 2017, 11:34:44 pm »
Quote
I see, I misunderstood which hash/information you were checking in this recent update.
The way I understand it now, after your clarification, - you (Aquamail) are already checking for the hash that identifies the CA issuing the certificate.
My apology for the misunderstanding and the unnecessary noise about that aspect.

A followup question that I have to that: What would happen if a Gmail cert changes, and Aquamail detects a change in the hash/signature of the CA? Does it effectively behave as before, i.e. offering the same "comparison" page, and giving an option to accept that manually? Or what?

Not the CA.

Google has a special "issuer" certificate that they use for (Gmail at least) and looks like all Google certs.

This is explained at the link I posted above.

[ well known CA: GeoTrust Global CA ] -> [ Google G2 Internet Cert ] -> [ Gmail certs ]

Yes, I read that to some extent, but thank you for providing the digest.
I might be wrong with the terminology (and Google might be using somewhat different terminology from what I've seen before), but the term that applies to that is "subordinate CA" (whereas "GeoTrust Global CA" is the "root CA", the one that is included in the "trusted CA's" list with web browsers and with OSes (Windows, Android, etc.)).

I believe Google also uses the same terminology here: https://pki.goog/


Aqua recognizes the issuer cert - the Google G2 Internet Cert - and silently accepts any "end" certificates coming from this special issuer.

Nobody outside of Google has access to the "Google G2" certificate (or at least I hope this is the case) and cannot issue certs "from" this cert, and therefore, the above is safe.

---

Compare to Office 365 for example:

[ DigiCert Cloud Services CA-1 ] -> [ outlook.office365.com ]

The issuer - DigiCert Cloud Services CA-1 - is not specific to Office 365 or Microsoft, so we can't do this kind of trick.

I think I understand the logic you explained here, but here is what I think about it:
It is very unlikely that the same CA would issue a rogue certificate for the same CN. A more likely scenario for a MITM attack is that a different CA would issue a certificate that would try to impersonate the certificate of the server we are connecting to. So, the same type of check, while it doesn't provide a full security, makes accepting a changed certificate slightly more secure. And that is what mechanism that uses CAA dns record relies on.
The difference is that in this case you are not querying who is the designated CA for the given server, but relying on the previously known CA. This, of course would be prone to an error in case the server owner would switch the CA.

I would say that the following logic sounds very reasonable to me (for any server):
[Aquamail detects cert change] -> [Aquamail compares the old CA hash to the new CA hash] -?>
? If different -> Gives warning/error message and displays both certificates
? If the same ->? If track-cert-change=ON ->? displays both certificates, indicating that CA is the same.
                      ->? If track-cert-change=OFF -> does nothing


Yes, I've seen all the alternative names for the google.com cert before.
BTW, the interesting thing is that Google's CAA record is defined (see below), but Gmail's (and I tried imap.gmail.com, smtp.gmail.com, and the hostnames to which this two point as CNAME) is not. Also, note the incomplete

> dig google.com type257

; <<>> DiG 9.9.9-P6 <<>> google.com type257
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37626
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.                    IN      CAA

;; ANSWER SECTION:
google.com.             60      IN      CAA     0 issue "symantec.com"
google.com.             60      IN      CAA     0 issue "pki.goog"

;; Query time: 14 msec
;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: Thu Sep 07 15:36:02 EDT 2017
;; MSG SIZE  rcvd: 97




Re: DNS CAA records

Yes I've heard about them.

Can't create one for my web site (Linode), and they don't seem very widely used yet.
I think it is coming soon.
Read here:
https://twitter.com/linode/status/852779888033505280?lang=en
and here:
https://forum.linode.com/viewtopic.php?p=73213 , in particular the 2nd post and references therein:
"Originally the implementation of CAA was voluntary: CAs could decide whether they would check for the records or not. However, in March 2017 the CA/Browser Forum voted in favor of a rule that will make CAA mandatory for all certificate authorities.[7] Starting September 2017 all certificate authorities have to implement CAA checking: "

It does help somewhat - but only severely limiting what options are available to the malicious party for creating his/her MITM cert.


But it does not directly prevent such party from doing their bad deed.
None of security measures are absolute. They all limit the ways malicious deeds could be done.

Wonder why there isn't a "side channel" for validating the "expected" cert directly? Say some other DNS record?
I am not quite sure what you are proposing here.
Just one comment: the current implementation of DNS is vulnerable by itself. DNSSEC and a few other techniques are trying to improve it, but...


PS. In all honesty, this discussion and changes proposed herein are moot until that big security hole in the present implementation of SSL(TLS) certificate checking is fixed.
But maybe you can implement at least some of the changes proposed here, while you'd be fixing that issue.