Re: Fixing exchange of host keys in the SSH key exchange
"denis bider \(Bitvise\)" <ietf-ssh3@denisbider.com> Sat, 25 March 2017 18:28 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 5D8621294C2 for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Sat, 25 Mar 2017 11:28:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.861
X-Spam-Level:
X-Spam-Status: No, score=-3.861 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.com
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 hgTO6CS3pSiA for <ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com>; Sat, 25 Mar 2017 11:28:55 -0700 (PDT)
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 9FA081288B8 for <secsh-tyoxbijeg7-archive@lists.ietf.org>; Sat, 25 Mar 2017 11:28:55 -0700 (PDT)
Received: by mail.netbsd.org (Postfix, from userid 605) id BF0E9855AF; Sat, 25 Mar 2017 18:28:47 +0000 (UTC)
Delivered-To: ietf-ssh@NetBSD.org
Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id D2B7685589 for <ietf-ssh@NetBSD.org>; Sat, 25 Mar 2017 18:28:38 +0000 (UTC)
X-Virus-Scanned: amavisd-new at netbsd.org
Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.com
Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 6zpuszmJ65yl for <ietf-ssh@netbsd.org>; Sat, 25 Mar 2017 18:28:38 +0000 (UTC)
Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id E3F5D84CDE for <ietf-ssh@NetBSD.org>; Sat, 25 Mar 2017 18:28:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=53olr3EfTKczBSP1hSskOrX/Dwgmwc2hJfLH0Y24JVQ=; b=hzGgjZqW8/Mqj6OBLgzYWCw93gKrnRHC41M+sh4FTfeoC2IeANOW408ivUzHwKKrZzakbnh27KSG1 T7GD7dXWpFmFLztwWayWQQIW2P+qS4Vg2M9L/kyEvG/Tnedb0OHkXhwk7YWzXgWkLynxwtZGP4KBdE w4MU1HA7yrz53M0mPAHqM82jyFk4YcCZ2HB3WCGLdq8J15R9jZd58oxA+9Mpd9VcqKTrg5ge3m5Tvb lldVwoFoB7FfBNL0u+F+Wd2Y+7F7yqhFt0k9TW7VoMiOorXhRYusxS1fLBnU8audoqpEu5WzAYQsOL K2cWP0Q/dr5Yn0myMsUBBQA+Wm8w+Kg==
X-Footer: ZGVuaXNiaWRlci5jb20=
Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com with ESMTPSA (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Sat, 25 Mar 2017 18:28:16 +0000
Message-ID: <589D55C2CF5942E9910482788CBDB445@Khan>
From: "denis bider (Bitvise)" <ietf-ssh3@denisbider.com>
To: Mouse <mouse@Rodents-Montreal.ORG>, ietf-ssh@NetBSD.org
References: <2216143EDEE342A3A5C9BB786F7FEF7A@Khan> <201703231224.IAA22091@Stone.Rodents-Montreal.ORG>
In-Reply-To: <201703231224.IAA22091@Stone.Rodents-Montreal.ORG>
Subject: Re: Fixing exchange of host keys in the SSH key exchange
Date: Sat, 25 Mar 2017 12:28:23 -0600
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3528.331
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331
Sender: ietf-ssh-owner@NetBSD.org
List-Id: ietf-ssh.NetBSD.org
Precedence: list
Mouse: > > if the client has to communicate one or more fingerprints > > of the server's host key(s) before KEXINIT, this prevents > > the situation where the client will present the user with > > a host key verification dialog, and the user will just > > click through it. > How? A server that enforces this policy (not all would) will reject the connection outright if the client fails to send at least one correct Expect-Key. The client must therefore have it. > Yes...but if the server does that, it also becomes > impossible for the client to do the now-usual "just > accept the key on the first connection" thing. Preventing this, and requiring a stringent host key setup, is the central feature of this mechanism. It's an option that some of our users would like. > You have to provide the host key to the client by > some out-of-band means. Yes. The idea is to make sure this actually happens. > Another possible benefit would be automatic defeat of > host-key-gathering bots. Interesting. Yes, that would be a side effect for hosts that configure this policy. > I strongly suggest that it instead be something like > Expect-Key: <hash-algorithm-name> <base64-hash> Agreed. Yes, definitely - for the reasons you described. > I can't help wondering if perhaps this is time to use > the uint32 in SSH_MSG_KEXINIT that is "0 (reserved for > future extension)", Unfortunately, there exist implementations that disconnect, or generate an invalid key exchange hash, if that value is not zero. When I last checked in 2015, libssh was one. > Also, 4253 says the server MAY send text before its > version number, but is silent on the question of > whether the client also may. Hmm, keen observation. Of course, even if it did say otherwise, there could exist server implementations that do not handle this properly. It seems that testing would be in order. > It seems more elegant to me for the server to signal > support with something like > Accept-Expect-Key: yes Or maybe the server sends something like "Expect-Key: support|require". The format can vary between client and server. That might still not work if there are clients that violate 4253, though. Another way that would work for sure would be: - The server includes "expect-key" among its host key algorithms. The client never includes this algorithm. Instead it just sends signature algorithms that correspond to keys it knows for this server. - If client sees "expect-key" among server's host key algorithms, then immediately after its own KEXINIT, it sends a newly defined message, SSH_MSG_EXPECT_KEYS, which contains fingerprints of host keys trusted for this server. The server can now act according to its policy, based on whether it receives SSH_MSG_EXPECT_KEYS, and what it finds in it. This approach has downsides compared to Expect-Key before version string: - If client is required to send Expect-Key before version string, server can just be quiet and send nothing. The server can avoid being accurately fingerprinted. The server can't do this in the method that uses KEXINIT. - The method that requires EXPECT_KEYS after KEXINIT complicates guessed key exchange, since the client does not know upfront if the server supports it. Generally, if the client could send fingerprints without the server signaling anything, this would be superior. It would allow the server to not let itself be fingerprinted as accurately. (The OS can still be fingerprinted based on properties of its TCP stack, even if the SSH server application sends nothing.) denis ----- Original Message ----- From: Mouse Sent: Thursday, March 23, 2017 06:24 To: ietf-ssh@NetBSD.org Subject: Re: Fixing exchange of host keys in the SSH key exchange > Iâ??m wondering if anyone - OpenSSH and PuTTY in particular? - would > be interested in implementing an extension to the way the initial SSH > handshake is done, in a way that would allow the SSH server to > require the client to communicate one or more fingerprints of the > serverâ??s host key(s), before exchanging KEXINIT. > This would have multiple benefits: > (1) Security benefit: [...] if the client has to communicate one or > more fingerprints of the serverâ??s host key(s) before KEXINIT, this > prevents the situation where the client will present the user with a > host key verification dialog, and the user will just click through > it. How? As far as I can see, in order to do that, you have to move that decision from the client to the server. This carries its own prices. > (2) Security benefit: on servers that enable this policy, and prevent > connections where the client does not communicate a correct server > host key, drive-by password guessing becomes largely impossible, > since unknown attackers do not know the serverâ??s host key. Yes...but if the server does that, it also becomes impossible for the client to do the now-usual "just accept the key on the first connection" thing. You have to provide the host key to the client by some out-of-band means. This of course could be an upside or a downside, depending. > (3) Practical benefit: the server [...] can avoid the situation where > introduction of a new host key, with no change to previous host keys, > would break connections for existing clients that prefer to negotiate > the algorithm of the new host key, but do not actually trust it. True. Another possible benefit would be automatic defeat of host-key-gathering bots. My logs are full of clients that connect, get my host key, and then disconnect. A few of them are honest about what they're doing ("SSH-2.0-ZGrab ZGrab SSH Survey", or "SSH-2.0-OpenSSH-keyscan"); others are...less so ("SSH-2.0-PUTTY"). Most just report a library version (eg, "SSH-2.0-sshlib-0.1"). Or, rather, clients used to be doing that; I now disconnect such clients before giving them any host keys (I prefer to not talk about the details of what I've configured my server to require to get it to talk to a specific client). > Implementation: > We have room for textual data that can be sent before the SSH version > string. To implement this, the client would send one or more lines > such as: > Expect-Key: <base64-sha256-fingerprint>\r\n I strongly suggest that it instead be something like Expect-Key: <hash-algorithm-name> <base64-hash> so that when SHA256 finally shows weaknesses, it does not become a major headache to switch hash algorithms. If the server thinks the hash algorithm is too weak, or doesn't recognize it at all, it can ignore that line. The client can of course send hashes of the same key under multiple algorithms, if it wants. I can't help wondering if perhaps this is time to use the uint32 in SSH_MSG_KEXINIT that is "0 (reserved for future extension)", though, rather than shoehorning it into something that's currently outside the protocol (almost) entirely. I see no guidance in 4253 for implementation behaviour if that value isn't 0 - but see below. Also, 4253 says the server MAY send text before its version number, but is silent on the question of whether the client also may. (I suspect most server implementations share that code with their corresponding client implementations, though.) > However, we could also change the protocol to include the Expect-Key > lines in the SSH key exchange hash. In this case, the client would > signal support by sending at least one Expect-Key line, and the > server would signal support in another way. One way would be to > include the name "expect-key" among its host key algorithms in > KEXINIT. The server has at least as much room to send text before its version string as the client does. It seems more elegant to me for the server to signal support with something like Accept-Expect-Key: yes there - or perhaps to use that RFU uint32 in SSH_MSG_KEXINIT if the client signals support (which would avoid the issue of an unaware client printing that and thus confusing the user and possibly breaking scripted uses, and also restrict nonzero values to implementations that have already advertised awareness of this extension). /~\ 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
- Re: Fixing exchange of host keys in the SSH key e… Mouse
- Re: Fixing exchange of host keys in the SSH key e… denis bider (Bitvise)
- Re: Fixing exchange of host keys in the SSH key e… Peter Gutmann
- Re: Fixing exchange of host keys in the SSH key e… Mouse
- Fixing exchange of host keys in the SSH key excha… denis bider (Bitvise)
- Re: Fixing exchange of host keys in the SSH key e… Mouse
- Re: Fixing exchange of host keys in the SSH key e… Peter Gutmann
- Re: Fixing exchange of host keys in the SSH key e… Mouse
- Re: Fixing exchange of host keys in the SSH key e… Peter Gutmann
- Re: Fixing exchange of host keys in the SSH key e… Peter Gutmann
- Re: Fixing exchange of host keys in the SSH key e… denis bider (Bitvise)
- Re: Fixing exchange of host keys in the SSH key e… denis bider (Bitvise)
- Re: Fixing exchange of host keys in the SSH key e… Mouse
- Re: Fixing exchange of host keys in the SSH key e… Mouse
- Re: Fixing exchange of host keys in the SSH key e… Peter Gutmann
- Re: Fixing exchange of host keys in the SSH key e… denis bider (Bitvise)
- Re: Fixing exchange of host keys in the SSH key e… Peter Gutmann
- Re: Fixing exchange of host keys in the SSH key e… denis bider (Bitvise)
- Re: Fixing exchange of host keys in the SSH key e… Mouse
- Re: Fixing exchange of host keys in the SSH key e… Mouse
- Re: Fixing exchange of host keys in the SSH key e… Mouse
- Re: Fixing exchange of host keys in the SSH key e… Peter Gutmann
- Re: Fixing exchange of host keys in the SSH key e… Peter Gutmann
- Re: Fixing exchange of host keys in the SSH key e… Peter Gutmann
- Re: Fixing exchange of host keys in the SSH key e… Peter Gutmann
- Re: Fixing exchange of host keys in the SSH key e… Peter Gutmann
- Re: Fixing exchange of host keys in the SSH key e… Mouse
- Re: Fixing exchange of host keys in the SSH key e… denis bider (Bitvise)
- Re: Fixing exchange of host keys in the SSH key e… denis bider (Bitvise)
- Implementation-hazards list [was Re: Fixing excha… Mouse
- Re: Fixing exchange of host keys in the SSH key e… Mouse
- Re: Fixing exchange of host keys in the SSH key e… denis bider (Bitvise)
- Re: Implementation-hazards list [was Re: Fixing e… Peter Gutmann
- Re: Implementation-hazards list [was Re: Fixing e… Darren Tucker
- Re: Implementation-hazards list [was Re: Fixing e… Mouse
- Re: Implementation-hazards list [was Re: Fixing e… denis bider (Bitvise)
- Re: Implementation-hazards list [was Re: Fixing e… Mouse
- Re: Fixing exchange of host keys in the SSH key e… S.P.Zeidler
- Re: Fixing exchange of host keys in the SSH key e… denis bider (Bitvise)
- Re: Fixing exchange of host keys in the SSH key e… Mouse