On Friday, 26 April 2013 16:13:58 CEST, Mike Cardwell wrote:
Yes, this is perfectly acceptable behaviour for SMTP also.
This bug concerns me: https://projects.flaska.net/issues/623
"The SMTP code does not invoke STARTTLS unless explicitly configured by
the user. It would be great to do this when e.g. the server advertizes
STARTTLS and does not offer a supported AUTH method."
I don't think you should opportunistically use STARTTLS in this
way.
It isn't clear to me why it's OK for IMAP to work like that, but not for SMTP.
Bug #623 is to make the SMTP client work exactly like the IMAP one.
So... Imagine you visit an
untrusted network after configuring up Trojita in this manner. A MITM
could modify the contents of the servers EHLO response to remove
"STARTTLS" from the list of supported extensions, and add unsafe
authentication methods (PLAIN/LOGIN) into the response at the same time,
which would cause Trojita to perform the authentication in an insecure
manner rather than upgrading to an encrypted channel first.
You're right, there's definitely a vulnerability here, both in the current IMAP
implementation and in the planned change to the ESMTP one. Perhaps it would make sense to
silently modify the user's settings during a first succesfull connect when the code
decided to "upgrade" to STARTTLS without being told so by the user?
This won't help when the user is MITMed during the first connect, but I don't
see what we can do here anyway (except making STARTTLS active by default, which
is probably a good idea).
Just another related thought. It would be nice if Trojita "noticed"
that STARTTLS was available, and warned the user that they're not
taking advantage of it (if they aren't). This could be a one off
warning, and wouldn't necessarily happen at initial configuration
time. Imagine for example, your mail provider decides to start
offering SSL six months after you configure up Trojita to use them.
That's a great idea; I agree that the settings UI can be made more robust and intuitive, and providing helpful suggestions on how to achieve the most secure connection method would definitely apply.
Do I have to mention that patches are very, very welcome? :)
With kind regards,
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
