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.
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?
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?
If a $tunnel connection is not considered secure, should unencrypted IMAP PREAUTH abort if $ssl_force_tls is set, regardless of $tunnel?
-- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
