[Freeipa-users] FreeIPA and FQDN requirements

[Simo Sorce]

On Fri, 2014-08-08 at 14:39 -0600, Rich Megginson wrote:
> On 08/08/2014 02:35 PM, Simo Sorce wrote:
> > On Fri, 2014-08-08 at 10:09 -0600, Rich Megginson wrote:
> >> On 08/08/2014 08:57 AM, brendan kearney wrote:
> >>> Kerberos is dependent on A records in dns.  The instance (as in
> >>> principal/instance at REALM) should match the A record in dns.
> >>>
> >>> There is absolutely no Kerberos dependency on hostnames being fully
> >>> qualified.  I have all my devices named with short names and I have no
> >>> issues with Kerberos ticketing.
> >>>
> >>> This seems to be an artificial requirement in FreeIPA that is wrong.
> >>>
> >> The other hostname requirement is for TLS/SSL, for MITM checking. By
> >> default, when an SSL server cert is issued, the subject DN contains
> >> cn=fqdn as the leftmost component.  clients use this fqdn to verify the
> >> server.  That is, client knows the IP address of the server - client
> >> does a reverse lookup (i.e. PTR) to see if the server returned by that
> >> lookup matches the cn=fqdn in the server cert.  This requires reverse
> >> lookups are configured and that the fqdn is the first name/alias returned.
> > This is incorrect, clients check that the name they've been told to use
> > matches what the certificate says is the name of the server.
> >
> > PTR records are never and *should never* be used to check certificate
> > names or it would be absolutely trivial to MITM clients by redirecting
> > them to a different IP address or spoofing the PTR reply from DNS to a
> > certificate that is completely unrelated to the server you wanted to
> > connect to.
> 
> Sorry.  Yes, you are correct.  The TLS/SSL client does not do a PTR 
> lookup, it does an A/AAAA lookup of the host specified in the server 
> cert subject DN, then sees if that IP address matches the IP address of 
> the server from the network connection.

Nope, it doesn't do this either.

The application may do a DNS A/AAAA request to find out what is the
server IP (although that may also be set in /etc/hosts locally) *before*
it even tries to connect to the server (and therefore before seeing the
certificate). Once it has connected though it just does a straight
comparison of the name requested by the user with the name in the cert.

If it did a DNS lookup of the name found in the cert it would be subject
to the same MITM attack by presenting a randomly named cert and then
spoofing the A/AAAA DNS request.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York