Follow up to #22133 and #22134 where PLAIN auth will only be used when TLS is negotiated. There's a wider problem though that the email data can be read/modified by a MITM who removes offers of TLS from the server.

If some adversary removes offers of TLS from the wire, then TLS is not negotiated. If TLS is not negotiated, PLAIN auth will not be used (upon resolution of the aforementioned issues). Given those constraints, what formal notion of security is being violated in addition to the two existing issues?

@as the recent fixes cover harvesting of plaintext credentials, which is an improvement.

However, if SendMail is configured to use auth other than PLAIN, then it'll send data (the email) in plaintext when TLS negotiation is deliberately removed by the MITM. The email can be read or modified by the attacker.

To paraphrase, @stevenjohnstone's report here is about the fact that a MITM can sit in the middle and downgrade to non-TLS and then snoop any mail being sent. As of yesterday, passwords will no longer be sent, but the mail messages still are (and always have been).

I think it would be interesting to consider changing SendMail for Go 1.10 to force the use of authentication when an auth implementation is passed to SendMail.

That is, right now, SendMail does basically:

if server allows auth {
    if auth != nil {
        use auth
    }
}

If the auth is smtp.PlainAuth and it is invoked, it will reject non-TLS sessions. But the MITM can just suggest not using it, and SendMail plays along (and always has).

It could be that we should change this code to be:

if auth != nil {
    if server does not allow auth {
       return error // cannot authenticate
    }
    use auth
}

That way, if you pass smtp.PlainAuth, which requires TLS, to SendMail, then SendMail would be guaranteed to use it, in effect requiring TLS.

The thing that this would break is using SendMail with servers that may or may not permit authentication and the caller can't predict which. I don't see how that situation would reasonably arise in practice, though. It just seems odd: "here, send this mail, and who knows if you need a password but if you do here it is."

If the user supplies a password for a particular server, I think it's reasonable for SendMail to interpret that as a direction that the mail is intended for that server and only that server, and to take steps (namely make sure it uses the authentication) to ensure that.

That makes sense. Are there any other stdlib packages that may have more issues like this? It seems like historically most of the attention goes into crypto/* . SMTP wasn't a very popular package but godoc still shows ~1.7k imports.

Too late for go 1.10 but I'd still be interested to see this in Go 1.11 if anyone wants to send a CL. Thanks.

Change https://golang.org/cl/79776 mentions this issue: net/mail: enable SendMail to require TLS

given the go1.11 tree is open can someone help to kick off the try bot on https://golang.org/cl/79776