Integrity protection of fetches

[i.grok at comcast.net]

On Fri, Aug 06, 2010 at 12:54:23PM +0200, Till Maas wrote:
> On Fri, Aug 06, 2010 at 04:31:00AM -0500, Mike McGrath wrote:
> > On Fri, 6 Aug 2010, Till Maas wrote:
> > > On Thu, Aug 05, 2010 at 04:32:36PM -0500, Mike McGrath wrote:
> > > > We also use SSHFP records for those of you that want to enable
> > > > VerifyHostKeyDNS yes in their ~/.ssh/config files.  Not all of our hosts
> > > > have it but many of our 'user' based external hosts do (pkgs,
> > > > fedorapeople, fedorahosted, etc)
> > >
> > > Afaik the SSHFP records are not protected against tampering by an MITM
> > > attacker.
> > 
> > They're better then ssh alone.  They're only used for the first initation.
> > So you'd have to be MITM'ed on the first connection in which case you're
> > right, they wouldn't protect against that.
> 
> Afaik using the SSHFP records make SSH not warn the user that the host
> key is not verified. If SSH would e.g. warn that the host key is
> unknown, but at least matches the SSHFP record, then it might be a
> little better. But actually it makes MITM attacks easier, because if one
> tampers the DNS response and the SSH connection, then the user does not
> even get a warning on the first attempt, making the situation even
> worse IMHO.
> 
> And SSH is only vulnerable to MITM attacks on the first connection in
> general and I guess that SSHFP records are not used anymore after the
> first connection. What would they be good for when the host key is
> already known to SSH?

openssh is more paranoid than that. An unsigned, unvalidated SSHFP
record will be treated just like the server response is today -- the
user will be shown the fingerprint and asked if it's correct.

Only if the response is marked with the AD flag (indicating that the
resolver has checked the signature and it's ok) does openssh trust it
automatically.  I know this because I've tried all three: unsigned,
signed but no AD flag on the response, signed with AD flag.

If you really want to argue about security, I'll point out that this
isn't completely bulletproof the way Fedora works today.  The host (your
computer) runs a stub resolver that communicates with the recursive DNS
server (typically another computer) over an unauthenticated connection.
The stub resolver trusts the recursive resolver to only set the AD flag
in its response when the answer is trusted, and to not set it when it's
not.  If you're talking directly to the authoritative nameserver, it's
not allowed to validate its own response, so it'll never set the AD
flag.

Ideally (from this perspective), the host would validate the response itself.