Description of problem:
If "StartTLS after connecting" is used as the IMAP+ encryption method, and the server not only doesn't offer TLS, but is also forbidding plaintext authentication, Evolution seems to go ahead and send the password in plain text.
I installed Dovecot (without configuring SSL, which I had used previously) and refreshed my e-mail account in Evolution, upon this message got displayed:
"Plaintext authentication not allowed without SSL/TLS, but your client did it anyway. If anyone was listening, the password was exposed."
Well, people are in fact listening, so if my password was actually revealed in this way, I would argue that this is a critical bug in Evolution.
A Telnet to port 143 returns this:
"OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LOGINDISABLED] Dovecot ready."
Version-Release number of selected component (if applicable):
The current version - 188.8.131.52.
Steps to Reproduce:
1. Install Dovecot without the use of SSL.
2. Configure a StartTLS account in Evolution.
3. Click Send / Receive.
The following message is displayed: "Plaintext authentication not allowed without SSL/TLS, but your client did it anyway. If anyone was listening, the password was exposed."
A message saying that the server doesn't support StartTLS, or something like that.
If this is in fact a bug, then a MITM attacker would probably be able to pretend not to offer TLS in order to force Evolution users to send their password in plain text.
Thanks for a bug report. Evolution's IMAPx uses whatever authentication method you configured it with. It even tries the STARTTLS, if the server supports it, which doesn't seem to be the case for the server (as it is not part of the capabilities).
What would be the right answer of the IMAPx in this case (it's when STARTTLS is configured, but the server doesn't advertise it in the capabilities)? Should the IMAPx give up with an error that such connection method is not available? I think the STARTTLS can be used even when not advertised, but I'm not sure.
Could you capture the communication between the IMAPx and the server, please? You can do that with a command:
$ CAMEL_DEBUG=imapx:io evolution &>log.txt
The resulting log.txt contains raw communication between the server and the client, but doesn't expose the LOGIN credentials. It would still be good to sanitize it for any private information you'd not want to share in public.
Also, could you open the account properties, select the Receiving Email tab and click the "Check for supported types" button in the Authentication type section, please? It'll contact the server and will strike-out (left enabled) authentication methods which the server supports and the IMAPx can use.
Thanks for the quick reply!
You say that you think that STARTTLS can be used even when not advertised, and were asking what the right answer of the IMAPx would be in this case. For me, it's was never about STARTTLS being advertised or used - it was about Dovecot's claim that the password has been sent in clear text, which I - as a user - would never want to happen as long as I have an encryption method set under Security in the Receiving Email tab (whether it's permitted by the relevant standards or not).
I have attached the log.txt file.
Using Wireshark, I could confirm that the password is indeed sent in the clear.
"Password" is the only authentication type that is not striked out after having clicked Check for Supported Types.
Actually, here is the content of the log.txt file:
[imapx:A] I/O: '* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LOGINDISABLED] Dovecot ready.'
[imapx:A] I/O: 'A00000 LOGIN ...'
[imapx:A] I/O: '* BAD [ALERT] Plaintext authentication not allowed without SSL/TLS, but your client did it anyway. If anyone was listening, the password was exposed.
A00000 NO [PRIVACYREQUIRED] Plaintext authentication disallowed on non-secure (SSL/TLS) connections.'
[imapx:A] I/O: ''
Thanks for the update. I thought the STARTTLS can be used even without advertised, but it's not the case, as your log shows. I was wrong here.
I agree with you with respect of the security concerns. I also do not like (I'm aloud when) my password goes through the Internet on an insecure connection.
The situation with your server is that it doesn't allow any login method, neither the STARTTLS. I cannot speak about SSL from the log, but you said above that you didn't install it yet, thus it's on the same boat.
Let's make the connection to an IMAP server fail, when a STARTTLS is requested by the user, but it is allowed/advertised by the server, rather than fallbacking to a non-secure connection. That way the user will be able to setup non-secure connection on his/her own responsibility, instead of being given surprise of this kind (and also unexpected behaviour).
Thank you! :)
I can confirm that the server did not offer SSL (Dovecot was configured for "ssl = no").
I think it's a good idea to not fall back to a non-secure connection, like you said, whether the server allows any insecure login methods or not.
After testing this further and checking the sources, the code to fail on the STARTTLS if not advertised/supported by the server is there, but it had two bugs in it:
1) the error variable being used for the error reporting was chosen a wrong
one, the local variable instead of the global (function argument)
2) the function returned success, instead of failure
I fixed both with the below commit. With it, I get a UI error "Failed to connect to IMAP server imap.server.com in secure mode: STARTTLS not supported" and the imapx:io log shows no LOGIN attempt.
Created commit f26a6f6 in eds master (3.21.2+) 
Created commit f2cc217 in eds gnome-3-20 (3.20.3+)
Brilliant - thank you very much, Milan!