What's the best way to check and enforce TLS connection? about go-smtp

[emersion]

We want to check and enforce secure connection before AUTH command to prevent credential leak.

That's the default behavior. AllowInsecureAuth will turn that off.

[iredmail]

If i understand the source code[1] correctly, with AllowInsecureAuth=false, go-smtp disables AUTH (by not advertising the AUTH support) but it continues the smtp session, right? What we want is terminating or closing the smtp session instead.

go-smtp/conn.go

Lines 253 to 260 in b4236a6

	if c.authAllowed() {
	authCap := "AUTH"
	for name := range c.server.auths {
	authCap += " " + name
	}
	caps = append(caps, authCap)
	}

[emersion]

I don't understand why one would want to advertise AUTH while always sending an error while it's used.

[iredmail]

Misconfiguration.

[emersion]

Please elaborate... If I had to guess, is it to give users a clear error when they try to setup their client but forget to enable encryption?

[iredmail]

Hi @emersion

Thanks for the patience and helping.

Our smtp "clients" are multiple MTAs, not MUA. And we force secure smtp connection for secure traffic. If a MTA doesn't enable / establish secure connection, we reject (with a clear error message, of course) and terminate the connection to prevent leaking credentials in AUTH directive until it's properly configured.

In this case, AllowInsecureAuth is not the solution since it continues the session.

Maybe it's better to add some more methods to Session interface to allow developers to handle connection or data in different smtp state, for example:

• right after connection is established. This is the best state in smtp session to perform IP address or reverse hostname based whitelisting and blacklisting.
• right after EHLO. Again, HELO hostname based white/blacklisting.
• right after STARTTLS (it 's called no matter it's secure or insecure connection). Good state to check and enforce secure connection.

Your opinion?

[iredmail]

@emersion Any update?

[emersion]

Insecure suggestion, leaks credentials, do not implement

Right, thanks for explaining, that makes sense. I'd suggest:

• Set AllowInsecureAuth = true
• In the Backend's NewSession function, check whether the connection is TLS or not, store that info somewhere in the returned Session, and return an error in AuthPlain.

[iredmail]

• In the Backend's NewSession function, check whether the connection is TLS or not, store that info somewhere in the returned Session, and return an error in AuthPlain.

Hi @emersion,

Thanks for the reply, but this suggestion won't work.

I tested this before created this issue, and double tested moment ago: it doesn't work with STARTTLS.
I used testing code like below:

func (b *Backend) NewSession(conn *smtp.Conn) (session smtp.Session, err error) {
	ip, _, _ := utils.GetIPPortFromNetAddr(conn.Conn().RemoteAddr())

	state, _ := conn.TLSConnectionState()
	fmt.Printf("DEBUG Version: [%s] %d", ip, state.Version)

	// ... omit other testing code here...

• When client establishes connection, the state.Version is 0 (which means insecure connection)
• Then client issues STARTTLS smtp directive in same smtp session, NewSession is called again(?) and state.Version is now 772 (TLSv1.3, cipher suite is TLS_AES_128_GCM_SHA256).

Since NewSession is called before STARTTLS directive, we cannot judge whether it's secure in this stage, and smtp.Session doesn't have a public method for starttls directive. So we still have to check this in AuthPlain() which may already leak the account credential sent by AUTH directive.

Can we add more public methods to smtp.Session to handle more smtp stages? e.g. before AUTH.

[emersion]

What you're asking for protocol-wise is not possible. Clients may send either STARTTLS or AUTH directly, and there is no way to know in advance. If the client decides to send AUTH without STARTTLS, the credentials are leaked.

The AUTH command contains an optional initial response argument, which in the case of PLAIN contains the username/password.

[iredmail]

ok, i will live with it. Thanks very much for helping. :)