SSL implementation

[johnny_0]

Hi all,

Just to make sure no one will take offence -- I am just asking a question, not making a statement .

I happened to stumble upon this today: www[.]app-ray[.]de
Basically they are saying that a large number of Android apps has weaknesses in their SSL implementation. Obviously for a good reason they do not provide a list of affected apps.

Is there any way of knowing that the SSL implementation in Aquamail is flawless and secure? Again, I am not saying it is the case, I am just wondering whether the proper functioning has been positively confirmed.

Regards,
Johnny

[Kostya Vasilyev]

While I can't comment on what app-ray does ("a combination of static and dynamic code analysis"), I can tell you this much:

My code uses SSL built into Android. It does nor carry around its own implementation (as that would be cumbersome, and also require me to get a permission for export of my software from the US Government).

Now, there are many different SSL ciphers, and the default choices made by Android system code have been questioned by security experts.

You can find more info by Goolging for "andorid ssl ciphers".

Recent development builds of AquaMail, posted here on the forum, have a setting under Networking to "harden SSL" which, when enabled, gives higher priority to the more secure (and more computationally expensive) ciphers.

[johnny_0]

Hi Kostya,

Thanks for clarifying this.

What I was/am concerned about in particular is how Aqua-Mail would react in case of a MITM attack. May I ask to more questions?

1- Does Aqua-Mail only accept certs issued by recognised CAs?
2- What would happen if A-M was presented a bogus or self-signed cert? I do not have the opportunity to test A-M against a mail server without a proper cert ;-). Would there be some sort of notification like "Do you trust this certificate?"?

Thanks
Johnny

[Kostya Vasilyev]

1 - The default "SSL (strict)" and "STARTTLS (strict)" only allow trusted CA.

2 - For self-signed certs, the user has to enable "SSL (accept any)" or "STARTTLS (accept any)" when configuring the account.

A connection configured with "strict" will fail if the certificate changes to a self-signed one (even if it happens at a later point, not during setup).

There is no domain name validation, because it's very, very uncommon for hosted domain accounts to use a certificate matching the custom domain (e.g. imap.bikinicarwash.com is actually imap.mailservice.com, whose SSL certificate has "*.mailservice.com" at best).

[johnny_0]

Hi Kostya,

Thanks a lot for this comprehensive answer. I have to admit, though, that it frightens me considerably.

1 - The default "SSL (strict)" and "STARTTLS (strict)" only allow trusted CA.

That's grand.

2 - For self-signed certs, the user has to enable "SSL (accept any)" or "STARTTLS (accept any)" when configuring the account.

That's also reasonable.

A connection configured with "strict" will fail if the certificate changes to a self-signed one (even if it happens at a later point, not during setup).

That's also grand.

There is no domain name validation, because it's very, very uncommon for hosted domain accounts to use a certificate matching the custom domain (e.g. imap.bikinicarwash.com is actually imap.mailservice.com, whose SSL certificate has "*.mailservice.com" at best).

This is what really worries me.

If I understand correctly, AM will accept _any_ cert as long as it has been issued by a trusted CA? That means a MITM could present a random cert to intercept my communication with my mail server if the malicious cert is from a CA? In other words, anyone who has control over a network node along the way to my email server could perform an MITM attack and AM would accept the cert? That could be e.g. the owner or operator of the WiFi access point in any airport, hotel, cafe, etc. This sounds like a nightmare scenario.

I do understand your point about the certs not neccessarily matching the servers' fully qualified names. However, I'd like to propose two features which should significantly mitigate the problems described above:-
1: To add an option to AM to show the cert used. Even if the cert doesn't match the server's name perfectly, it should very often give you a good hint as to whether or not to trust it. E.g. if the server's name is mail.company.com and the cert is issued to *.company-inc.com there is a reasonable likelihood that the cert is not forged or tampered with.
2: To _remember_ the cert used and its fingerprint. Whenever this cert/fingerprint changes, AM should show a warning. While there are legitimate reasons why a cert changes (e.g. old one expired, etc.), this shouldn't happen too often. Moreover, if one connects from an untrusted public network and the cert suddenly changes from *.company.com to *.iwanttohackyou.biz or any other unexpected, illogical cert, this should set off all alarm bells in the user.

Any feedback, also from others here on the forum, is much appreciated.

I believe that these two features would be very valuable and I would love to see them implemented in AM, especially as I think that AM generally is a great app.

Best regards,
Johnny

[Kostya Vasilyev]

Well, I'm certainly not an expert on security, but it seems entirely possible that a certificate from a (formally) trusted CA could have a fake domain name, like imap.gmail.com.

Of course I'm talking about low-cost SSL resellers, not the expensive certificates which require extensive personal or business identification.

I'm also very doubtful that someone who was going to engineer an MITM attack (with a properly rooted cert) would use "l33thaxor.com" or anything like that as the cert's domain.

If "imap.gmail.com" (and the like) seems possible, but not easy (one would have to really shop around and try and try) -- how about "imap.gmai1.com" or "out1ook.com"?

Did you spot the ones? How about in Android's default Roboto font?

How about something even more remotely removed from the real thing, like "microsoft.mail-experts.com"? Sounds trustworthy, doesn't it?

Because of all of the above, I don't see domain name validation as a very secure mechanism, even if it could be used. I'm not alone in this (there was/is a presentation on why the current "chain of trust" system is really not that secure... by a Chromium engineer... or was it Mozilla...)

Still - I do see a benefit in both things you mentioned, so I'll try to add them, as optional settings (as I did with SSL hardening).

[johnny_0]

Hi Kostya,

This is becoming an interesting thread .

Just a few comments more...

Of course an attacker could try to obtain fake certs from a recognised CA that are confusingly similar to 'real' ones. But... this cannot be done on the fly. If someone is snooping in a pubic WiFi network, he cannot know which certs he will come across. He could try to get a bunch of certs beforehand for the typical email domains (gmail, hotmail, etc.). However, it is impossible for him to obtain a cert for a random mail server on the fly. So being able to check to whom a cert is issued does provide some protection -- it renders it impossible to intercept connections via MITM attack with some sort of wildcard cert.

Second, remembering the cert for a given email server has the beauty that one can try to connect to that server from a 'trusted' network when connecting for the first time, thus minimising the probability of an attack and increasing the chance of getting the real cert and have it stored by AM.

Third (but this is admittedly not easy and I would not expect you to implement this), there is a technique that Google (AFAIK) calls cert pinning. Chrome knows which CAs are allowed to issue certs for some important domains. Let's assume all certs for Google domains are issued by CA-1 and Chrome is presented a valid cert for a Google domain from CA-2, it knows that this cannot be and shows a warning message.

Anyway, I am glad that I could make some suggestions for improvements that you appreciate and look forward to see them being implemented.

Best regards,
Johnny

[Kostya Vasilyev]

Yes, a generic sounding name like my "network-experts.com" example above -- can be installed ahead of time, and used to intercept connections to all mail servers.

And at that point (assuming the change is detected), it's the user who has to make a decision -- and I'm sure a generic name like that will seem trustworthy to some.

Even using *.google.com might work quite well,  including when connecting to @hotmail (just an example) -- "um, so Microsoft is working together with Google to protect me from the bad guys, great, accept!".

It's quite telling that you've put quotes around 'trusted' ("a 'trusted' network when connecting for the first time"). In theory, an employer, a residential ISP, a mobile operator could all have good reasons for proxying SSL traffic (although in that case, I'd expect their certs to be more explicit with their domain names).

Anyway, I'm glad you brought it up, thanks.

[Kostya Vasilyev]

I have news on this:

http://www.aqua-mail.com/forum/index.php?topic=2497.0