On 2020-06-21 10:59:05 -0700, Kevin J. McCarthy wrote: > On Sun, Jun 21, 2020 at 07:29:58PM +0200, Vincent Lefevre wrote: > > Well, there's still something that isn't clear. When the user uses the > > "imaps" protocol, I assume that the connection needs to be encrypted, > > whatever the value of $ssl_force_tls (and $ssl_starttls, but STARTTLS > > must not be used in this case). How is this handled? If I understand > > correctly, that "!idata->conn->ssf" below. > > Yes, conn->ssf is set in ssl_socket_open() / tls_socket_open(), so for imaps > it will be set prior to this check. > > It's also set after the STARTTLS TLS negotiation.
Now I'm confused. This means that $ssl_force_tls should be honored, i.e. if it is set, then Mutt should ensures that STARTTLS is used (whatever the value of $ssl_starttls). But your patch has a "!Tunnel" condition. This seems incorrect since if an unencrypted tunnel is used, then a MITM attack is possible at that point. So currently the expectation and behavior are inconsistent. > > The $ssl_force_tls option should also be clarified, e.g. when "imaps", > > "pops", etc. are used, but also concerning tunnels. > > > > BTW, the $tunnel option should be clarified too. If I understand > > correctly, there will be no attempt to use STARTTLS with a tunnel, so > > that the encryption needs to be done by the tunnel itself. The example > > uses "ssh", but that's not explicit. > > This brings up a question I was going to raise later about tunnels. > Currently using $tunnel does not set conn->ssf. So for pop://, smtp://, and > imap:// (to a non-preauth connection), Mutt will negotiate STARTTLS (subject > to the $ssl_starttls config). > > Aaron Schrab posted a patch in ticket 250, setting conn->ssf for $tunnel, > but I am not clear on what is expected of $tunnel either. Does $tunnel > imply Mutt can assume the connection is secure? A choice needs to be done and documented, possibly controlled by an option. And the behavior needs to be made consistent. Whatever choice, this needs to be announced as the changes could break existing configurations or make some of them insecure. > As you said, the examples show ssh or a direct pipe to the program, but are > there circumstances where the connection would be insecure, and is this > Mutt's responsibility? Nowadays, SSH is common and can identify the remote host[*], so that I think that it is acceptable that Mutt delegates the responsibility of the security to the tunnel. This also makes the configuration easier, IMHO. Of course, users who know that their connection is secure (secured LAN) could use an unencrypted tunnel. [*] By default, StrictHostKeyChecking is set to "ask", so that the user will have to confirm for the first connection. > If a $tunnel connection is not considered secure, should unencrypted IMAP > PREAUTH abort if $ssl_force_tls is set, regardless of $tunnel? Yes, obviously. That would be the only way to prevent a MITM attack in this case. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
