Re: Problem with SMTP/STARTTLS

[Brian Stafford <brian stafford uklinux net>]

On Thu, 28 February 23:48 Glenn Trigg wrote:
> One other thing I've just discovered...
> 
> It seems that the hostname you specify in the "Remote SMTP Server" field 
> must exactly match the CN in the servers certificate for the TLS connection 
> to work.
> 
> Is that correct?

For now, yes though ignoring case.  Checking the host name in the certificate 
is one of the most basic checks and no implementation should ever omit this.  
If the check fails, there is either a configuration error which is usually 
easily remedied, or somebody has launched a man in the middle or DNS spoofing 
attack.

At some point I may write the code to allow wildcard matches on the 
certificate CN (RFC 2818) and to check the subjectAltName extentions.  If this 
is a critical consideration I will do something about this.

BTW, if anyone out there knows the OpenSSL API reasonable I could use some 
help in accessing subjectAltName.

Checking over the code, when libESMTP checks the server certificate's 
credentials, libESMTP quits the session on failure, even when "if-possible" is 
selected (I'd forgotton this in my earlier reply - the code reminded me).  The 
reasoning is that if there is a misconfiguration the fix is easy.  If not the 
connection is under attack and there is no point falling back to a clear text 
connection to the same server.  If it did fall back, the attacker would 
succeed in their aims instead of causing the connection to abort.  If the 
certificate validation fails because it has expired and the user is assured 
that they have connected to a genuine server, they can always select "use tls 
never" and retry.

> I don't remember seeing that in the doco, but there was a reply to an 
> earlier TLS question that eluded to this.

You can take "if possible" to mean that if the server offers TLS it MUST be 
used.  A clear text connection is made only if the server does not offer the 
STARTTLS extension.

Regards,
Brian