Re: Fixing exchange of host keys in the SSH key exchange

Mouse <mouse@Rodents-Montreal.ORG> Mon, 27 March 2017 05:34 UTC

Return-Path: <bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org>
X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com
Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1314A126C7B for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Sun, 26 Mar 2017 22:34:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvtN804zL0QN for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Sun, 26 Mar 2017 22:34:22 -0700 (PDT)
Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA2C9126C7A for <secsh-tyoxbijeg7-archive@lists.ietf.org>; Sun, 26 Mar 2017 22:34:22 -0700 (PDT)
Received: by mail.netbsd.org (Postfix, from userid 605) id 6FE39855FF; Mon, 27 Mar 2017 05:34:22 +0000 (UTC)
Delivered-To: ietf-ssh@netbsd.org
Received: by mail.netbsd.org (Postfix, from userid 1347) id 2CF57855FD; Mon, 27 Mar 2017 05:34:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 2425A855F3 for <ietf-ssh@netbsd.org>; Mon, 27 Mar 2017 03:27:31 +0000 (UTC)
X-Virus-Scanned: amavisd-new at netbsd.org
Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id f9OgAnrALA94 for <ietf-ssh@netbsd.org>; Mon, 27 Mar 2017 03:27:30 +0000 (UTC)
Received: from Stone.Rodents-Montreal.ORG (Stone.Rodents-Montreal.ORG [98.124.61.89]) by mail.netbsd.org (Postfix) with ESMTP id 2AF07855EB for <ietf-ssh@netbsd.org>; Mon, 27 Mar 2017 03:27:29 +0000 (UTC)
Received: (from mouse@localhost) by Stone.Rodents-Montreal.ORG (8.8.8/8.8.8) id XAA25497; Sun, 26 Mar 2017 23:27:29 -0400 (EDT)
Date: Sun, 26 Mar 2017 23:27:29 -0400 (EDT)
From: Mouse <mouse@Rodents-Montreal.ORG>
Message-Id: <201703270327.XAA25497@Stone.Rodents-Montreal.ORG>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway.
X-Message-Flag: Microsoft: the company who gave us the botnet zombies.
X-Composition-Start-Date: Sun, 26 Mar 2017 22:26:16 -0400 (EDT)
To: ietf-ssh@netbsd.org
Subject: Re: Fixing exchange of host keys in the SSH key exchange
In-Reply-To: <B27F1BAE8F974449B6EE8B7DF50ED3A9@Khan>
References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <201703231224.IAA22091@Stone.Rodents-Montreal.ORG><589D55C2CF5942E9910482788CBDB445@Khan> <201703260243.WAA05983@Stone.Rodents-Montreal.ORG> <B27F1BAE8F974449B6EE8B7DF50ED3A9@Khan>
Sender: ietf-ssh-owner@NetBSD.org
List-Id: ietf-ssh.NetBSD.org
Precedence: list

>> I've encountered servers that misbehave â?? crash or something
>> equivalent from the client's point of view - when faced with the
>> string@domainname extension feature.
> I am flummoxed by the existence of such implementations.

So was I!

> Surely, that would not even be compatible with OpenSSH?

I don't know.  I suspect I tried OpenSSH against them, since I can't
imagine why I would have suspected it were DNS-based extensions causing
trouble without "works" and "fails" traces to compare, and OpenSSH is
the most plausible other implementation for me to have had at hand.
But it would have been OpenSSH of that era.  This was relatively long
ago; in particular, it was before 2008-07-03 - that's the oldest moussh
source tree I have at ready hand, and it's got -no-private (see below).

> Have you seen any of these recently?

No, but I haven't had much opportunity to, either.  (They were the SSH
listeners on devices such as switches.)

> Was that perhaps a decade ago, when OpenSSH maybe didn't have a
> KEXINIT full of string@domain algorithms by default?

That timing is about right.  I don't, and didn't, track what OpenSSH
does (resp. is doing), though.

> I do take the stance that a broken implementation is broken, but this
> does not change that I'm usually expected to do something about it,
> and folks want me to work around it so it works.

I sympathize.  Those switches (or whatever they were) are the reason
moussh has -no-private:

     -no-private
             Disables attempts to use private requests and algorithms (any-
             thing using the DNS extensibility mechanism, basically).  This
             should never be needed, but at least one commercial server is
             known to break when faced with such names.  [...]

> I'd like to think our implementation is close to defect-free, but
> chances are someone somewhere was tasked to implement a workaround
> for a bug that existed in our software, even if it had long since
> been fixed.

Probably.  Same goes for moussh, though it's more likely nobody has
cared enough since moussh surely has a much smaller user base.

> We judge our own software based on the next version we're about to
> release; and other people's software based on all versions that
> existed. :)

That is a common problem.  Stance.  Whatever you want to call it. :-)

>> Hmm, I think I'll give moussh a configuration option to send things
>> before the ID string, for exactly that reason.
> That would be amazing.  I could implement it as an option, but unless
> it is on by default, there's no way we'll get feedback.

I'll try to remember to mention it here when I finally get around to
adding it.  So far I've added it to nothing but my TODO list.

> At this point, the most feasible option I see is the type of probing
> you said you don't like: blind connections to random IP addresses to
> produce statistics how often it works or not.

Quite aside from whether it's moral to use others' servers for your own
purposes like that, that isn't going to tell you more than whether they
are willing to talk to you.  If they drop the connection, you will not
be in a position to tell whether it's because they crashed upon seeing
your pre-version text, or they're configured (as mine are) to refuse to
talk to third parties who don't exhibit whatever behaviour they're
configured to look for, or they crashed for an unrelated reason, or
what.  Also, would "fraction of random IP addresses with ssh servers
that don't crash upon seeing $THING" really be useful statistic, even
if were one you could get?

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse@rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B