* on the Fri, Apr 26, 2013 at 04:41:22PM +0200, Jan Kundr?t wrote: RESENT because I sent from the wrong email address. Please delete my other email rather than letting it through if it's in a moderation queue. If you see this email after allowing it through, don't worry about it.
>> 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. I don't think the spec or any recommendations for either SMTP or IMAP say that clients should opportunistically upgrade their connection. It just allows servers to advertise different authentication methods depending on whether or not SSL is in use. Which makes sense, because some authentication methods are safe over unencrypted connections and some aren't. >> 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? That sounds like a good idea to me. > 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). Defaulting to secure is always a good idea IMHO. And if you can warn users when they're doing something that isn't safe, that's even better. >> 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? :) To be perfectly honest, I've not actually even installed Trojita yet my self. I read a comment somewhere (Hacker News I think) stating that you might be getting PGP support at some point (A GSoC project maybe?), so subscribed so I could follow development. My server encrypts all of my incoming email with my public PGP key, which means I can't really use Trojita as my normal day to day client until it has PGP support. I will certainly install it at some point soon though, just to see if I can break it ;) -- Mike Cardwell https://grepular.com/ http://cardwellit.com/ OpenPGP Key 35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F XMPP OTR Key 8924 B06A 7917 AAF3 DBB1 BF1B 295C 3C78 3EF1 46B4
signature.asc
Description: Digital signature
