Actually, even this is completely wrong. You are understandably giving a charitable reading to the poorly worded explanation. I have tested this earlier today on an iOS 10.3.3 device and an iOS 11 device, and the TLS certificate is absolutely validated properly.
As you've stated with Test B, yes, if SSL is turned off then the information is indeed sent in plaintext during the account setup. However, I don't know what the purpose of this test was, as this is (as you said) expected behavior.
To be clear, here is what I did.
1. Settings->Add new account-> Exchange
2. Entered email ID (with @leakyx.com domain) and password and selected 'Next' (iOS 11 required hitting Next, and entering password on the next screen. iOS 9.3.5 has only one prompt for both email and password)
At this point, a dialog showed up about the cerficate not being valid. You have the option to continue and trust the certificate or hit 'cancel'
3. I hit cancel. (Which means, you don't trust the certificate)
The credentials still showed up. I did it twice to be sure.
On leakyx.com, [email protected] is with iOS 9.3.5 and [email protected] is with iOS 11
umm , yes?? Even a simple check would increase the complexity a successful attack. Yes it could be duplicated , but having a client that just dumps the credential without any verification does not sound like a good idea and is poor programming.
"Test B", however, is not a security issue at all, IMO; instead, it is "working exactly as intended".
> The Apache logs are not even needed without SSL enabled because the first request to the web server includes the username and password in clear text.
If SSL isn't enabled then, yes, of course it does. This may come as a shock to the author but standard IMAP4/POP3 without SSL also sends credentials in the clear (as does -- gasp! -- every other plain-text protocol!)
> Even when SSL is not enabled the client should not be sending the credentials without first verifying that it is a real exchange server.
And just how would the client do that? Using an (easily spoofable) "Server:" header in the HTTP response?
> Realistically the client should not even send the password before verifying the user exists.
That, however, would be an information disclosure vulnerability (identifying valid usernames on the server). That's why no other mail server in use on the Internet does that either. Not to mention that it's real easy for a malicious attacker (in control of the server) to lie about that too.
Aside: if you're running an Exchange server, set up Autodiscover [0] and all your users need to set up their mail account is their username and password (no server details are needed!). For other (i.e. non-Exchange) mail servers, there's a similar "Autoconfiguration" method that is supported by various mail clients, such as Thunderbird [1].
[0]: https://msdn.microsoft.com/en-us/library/office/jj900169(v=e...
[1]: https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird...