Re: SMTP/TLS (RFC 2487) server authentication question

[Lutz Jaenicke <Lutz.Jaenicke@xxxxxxxxxxxxxxxxx>]

Happy New Year!

Sorry, our campus backbone routers were more or less out for a holiday since
Dec. 31 (did not recover completely after a power failure and manual
intervention only started at Jan 03), so I could not answer earlier.

On Thu, Dec 30, 1999 at 12:43:27PM -0800, RL 'Bob' Morgan wrote:
> > MUST be checked against the hostname the client used to connect, there is
> > no information in RFC2487. (I also checked the ietf-apps-tls archive and
> > found no discussion about it.)
> 
> In section 5.1 of RFC 2487 there is:
> 
>    The decision of whether or not to believe the authenticity of the
>    other party in a TLS negotiation is a local matter. However, some
>    general rules for the decisions are:
> 
>     - A SMTP client would probably only want to authenticate an SMTP
>       server whose server certificate has a domain name that is the
>       domain name that the client thought it was connecting to.

Well, I interprete this as follows:
- My client is connecting to a host HOST.FIRST.DOMAIN to deliver mail for
  SECOND.DOMAIN, because the MX says so.
- My client therefore thinks it is connecting to HOST.FIRST.DOMAIN and
  should check this certificate.

> When a client gets a cert from a server via TLS, server authentication is
> accomplished by the client (and user) verifying the contents of the cert
> and determining that the information in the cert actually applies to the
> service entity that the user directed the client to contact.  
> Unfortunately "service entity" is not a well-standardized concept, even
> within particular application protocols.  To the user the service they're
> attempting to contact is probably "the online banking function of BigBank
> Inc", or "my MailZombies mailbox", or "the SMTP router for MegaSoftCo".  
> The fact that the server machines are called bnksrv1.bigbank.com and
> mail23.mailzombies.com and smtp.megasoftco.com is a mystery to the average
> person.  So if the attacker can trick the client into asking for
> bnksrv1.badguy.com when it thinks it's going to BigBank Inc, and get a
> cert (from a trusted CA) for that server (which may not be easy, of
> course) then the game has been lost.  This is the gist of some recent
> highly-publicized "SSL isn't secure" rants.
I see.

> So, all the client can really do without a fruitless appeal to the user is
> check that the hostname it is asked to contact is in the cert.  As you
> note, this hostname may be resolved via DNS into another hostname before
> turning into an IP address, and in the SMTP case this is very common,
> obviously.  A MX resolution step is just like the high-level-name to
> DNS-name step I describe above:  a chance for the attacker to insert bad
> info and foil the process.  If your client, as you state, only checks for
> the name after the MX lookup rather than the name it started with, then it
> allows the attacker to do this undetected, and hence provides less
> protection than the client that checks for the initial name.  Whether this
> is a terrible lapse in security or a practical compromise is in the eye of
> the beholder, I think.  (Note that Kerberos, in which clients do CNAME
> resolution if necessary before asking for a service ticket, suffers from
> this same problem.)
> 
> But I'm sure it's clear that if all clients check for the initial name,
> this will change what service deployers have to do drastically:  any time
> they add a new MX record for a host SMTP service, they'll need to modify
> the server cert for that service to add the new MX-able name.  If the
> server has 50 MXes, each one will have to appear in the cert.  This makes
> sense from a security point of view but would certainly trip up the
> typical admin, seems to me.
In deed, that is a No-Go. It would work for me, serving a small lab in
our university, but it could not be done in a larger scale.

> As a further complication, note that the PKIX cert RFC (RFC 2459) suggests
> (in section 4.2.1.7) putting a DNS-named subject into the subjectAltName
> extension of the cert, tagged as a dNSName type; though unlike
> email-address-named subjects the spec doesn't specifically discourage
> using the subject field for this kind of name.  But a robust client should
> be prepared to look in both places for the server's DNS name.
That is a good hint, I will check into this.

> Perhaps the right thing for an SMTP-TLS client is to have optional levels
> of strictness in its checking, defaulting to insisting on the
> pre-MX-lookup name being in the cert, but having an optional setting that
> would only ask for the post-MX-lookup name.  Probably there would be other
> useful knobs as well, regarding following of CA chains, etc.
Yes. I use OpenSSL, some lot of this is in the code by now, since the library
offers it in a comfortable way, but this is just abitrary. What is not in
the lib, is difficult to do :-)

Things would be easier, if I could explicitely _request_ a server certificate
by sending a "STARTTLS first.domain" and then the server could send me
an appropriate cert taken from the list, but this same problem also applies
to virtual hosting of TLS-enabled http services...

Best regards,
	Lutz Jaenicke
-- 
Lutz Jaenicke                             Lutz.Jaenicke@xxxxxxxxxxxxxxxxx
BTU Cottbus               http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik                  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus              Fax. +49 355 69-4153