Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it or lose it principle!

denis bider <denisbider.ietf@gmail.com> Sun, 03 May 2020 23:11 UTC

Return-Path: <denisbider.ietf@gmail.com>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16AB3A090C for <curdle@ietfa.amsl.com>; Sun, 3 May 2020 16:11:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 o5WQZ0bOp_DU for <curdle@ietfa.amsl.com>; Sun, 3 May 2020 16:11:38 -0700 (PDT)
Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A5453A08B5 for <curdle@ietf.org>; Sun, 3 May 2020 16:11:38 -0700 (PDT)
Received: by mail-ot1-x331.google.com with SMTP id c3so7422841otp.8 for <curdle@ietf.org>; Sun, 03 May 2020 16:11:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5zNV8cOjSK0M0kpLaFWa3dCS8TXsPuujwQS5UsKWH24=; b=j8zCPuDO5qmyuPZDwB8CCH+w6noVmOD0+GkeK5uF8myR5c6vp9EERRRQ0lY6qKxPzJ O/DPlsOQH7PhfdhESzTzrHqRqq5s+5p/sgxZu3O2HZM69tYzBXlZB1euErys9KzF5k5E Ux3fCoZlCz7I2u2qQC4Wse9VeCSpvJceCmY6gUlngcUic7CKRdMZgq06/bxTzlQQu9Nv /d4wb3M9NOxZZ2+C5zN/h7OODtDDujzf+hT6k49ptLWkrbjGVLf0bZ/NGNuk0hBX088e a3z8xxgmMPqacjsaMByhLCVrZVYyCpINm2Gg7Dt0T8FZpaG5brhKbZVkAApHYuXROO7K mgyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5zNV8cOjSK0M0kpLaFWa3dCS8TXsPuujwQS5UsKWH24=; b=WmLD4kNGoKZ7eis9QDBuKh168xUAygykQUHQYcwmHGMRYhJWnFI7mqblaO4JvGBdkp pj/b6glkNlORjfqtRyKiBO41033aaNf8tX4Ubuf7fO2vRdqShPZYAp4EcaJpgnNWmauM rj02G6T1N2gbeajekVly7sBSmGlNGvK7DaiXCFO4zM2+MjduhGulG535YJTabPxEMuKg /2XcG05o+pGgFRE3yS0wx4HDNvYsJNcaAkCyHLJ9eJN+/7qhudR8LxGEKi2mOzI8k9yQ nfRQFrATw73mbJ9mY2Sl1XN34f0iR25fgwk2puvXcY/vQNHjh2XjAZD7VnbisFDlE+UJ 3Rbg==
X-Gm-Message-State: AGi0PuYk5LJU4h4gcxaWsTFs894B77Q8hBD79KlVcaK18FOm6URD5H2O ZTJFcQXHV1aje5FEsXaoJAwPN6HQQmiJ4geoUKc=
X-Google-Smtp-Source: APiQypIR9wk5n8LRi3OCRa47i4qCVYx5tg5ilcEq4Xs+7KtpyD73rpYEZ64UTrVdAy71zI1BLtrnNRzUcYp5O/+FsnQ=
X-Received: by 2002:a9d:f68:: with SMTP id 95mr9972917ott.146.1588547497650; Sun, 03 May 2020 16:11:37 -0700 (PDT)
MIME-Version: 1.0
References: <CADPMZDBcOtUaUBJKn20yEpLi=pmse2SgiXpZXArAKLyKTeS-GQ@mail.gmail.com> <E15E856F-478A-499A-8A59-EB907099E777@timeheart.net> <CADPMZDAvv23SKg2ZiTBH+Ec6M135zonsnNFaiinAKwszj-ap8g@mail.gmail.com> <FD39369F-62BE-48D2-967E-0D70F9955E17@timeheart.net>
In-Reply-To: <FD39369F-62BE-48D2-967E-0D70F9955E17@timeheart.net>
From: denis bider <denisbider.ietf@gmail.com>
Date: Sun, 3 May 2020 18:11:26 -0500
Message-ID: <CADPMZDDEJtWGW1e9wb3-76MLUKK840pmXOj-VnDMvNNPg34=Nw@mail.gmail.com>
To: Ron Frederick <ronf@timeheart.net>
Cc: curdle <curdle@ietf.org>, ietf-ssh@netbsd.org
Content-Type: multipart/alternative; boundary="0000000000004e6f1705a4c689d8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/oTXVWGo_2L7_QelQopM0JAgRP4I>
Subject: Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it or lose it principle!
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 May 2020 23:11:41 -0000

> I do use global requests in both directions as part of the implementation
> of "keepalive@openssh.com”, but so far I haven’t run into any issues with
that.
> That’s disabled by default, though, so perhaps people are only enabling
> with peers that don’t have issues with global requests.

Features that are disabled by default end up being used in a small fraction
of connections in practice - I think it's not wrong to guess 1%. Problems
with them are further unlikely to be reported because the user assumes the
problem they experience is why the feature is disabled anyway.

I think the "hostkeys-00@openssh.com" mechanism is highly valuable. I would
like to see it more widely supported and enabled by default. Last I
checked, it was disabled by default, no doubt due to cherished clients that
disconnect when they receive it.

I would very much like it to be enabled by default, especially if the
client sends the "global-requests-ok" extension. Bitvise SSH Server enables
"hostkeys" if the client does this. If not, then we use built-in
compatibility rules based on the SSH version string to guess if it's safe
to send global requests.


> Does it fail on ANY global request being sent from a server, or is it only
> at certain points that it doesn’t handle these messages correctly?

The bug I was discussing here is that when operating as a server, the
Maverick implementation (and therefore servers that use it) has a bug where
it crashes if the client sends SSH_MSG_EXT_INFO. There is only one point in
the connection where the client is permitted to send SSH_MSG_EXT_INFO. This
is immediately after the client's first SSH_MSG_NEWKEYS.

Perhaps you mean to ask about clients which fail upon receiving global
requests from SSH servers? These fall mainly into two types:

(1) Clients that disconnect on receipt of ANY global request at any time.
These are outright negligent implementations: RFC 4254 requires the global
requests to be handled and responded to if "want reply" is true. You can't
send an active keep-alive to this kind of client.

(2) Clients that disconnect when in a special state, specifically when
expecting a channel open confirmation from the server. These are oversights
that were generally fixed in later versions of the software, but people
still use earlier versions that had the bug. When dealing with this type of
client, it's almost-safe to send an active keep-alive (very low chance of
client being in the crash-susceptible state). However, if the server is
sending the "hostkeys" global request, that usually happens at the same
time as the client is opening its first channel. Therefore, client-side
crash becomes very likely.


> Is RFC 8308 the right reference for this option? Are there
> any implementations of this so far other than from Bitvise?

Yes, RFC 8308 is the authoritative spec for the "delay-compression"
extension. Bitvise SSH Server and Client can be considered reference
implementations. As of right now I haven't been informed of others.


> Also, I’m not familiar with the PuTTY issue around needing a
> second key exchange. Is that documented somewhere?

The race condition is inherent in the zlib@openssh.com algorithm. PuTTY
identified this issue and addressed it with a strategy based on key
re-exchange. Bitvise SSH Client also uses the key re-exchange strategy if
the server advertises zlib@openssh.com but not the "delay-compression"
extension.

PuTTY project source on this issue:

https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/zlib-openssh.html

denis


On Sun, May 3, 2020 at 1:14 AM Ron Frederick <ronf@timeheart.net> wrote:

> On Apr 26, 2020, at 10:33 PM, denis bider <denisbider.ietf@gmail.com>
> wrote:
>
> Awesome!
>
> Yes, the idea of "global-requests-ok" is not to make the client do
> anything different. It's to reassure the server that the client won't
> violate the spec if the server sends a global request.
>
> The main motivating usage case is so the server can feel at liberty to
> send the global request "hostkeys-00@openssh.com" after user
> authentication:
>
> https://cvsweb.openbsd.org/src/usr.bin/ssh/PROTOCOL?annotate=HEAD
>
> This is essential functionality which allows clients and servers to change
> host keys without requiring administrative intervention at each client
> installation.
>
> Without "global-requests-ok", the server needs a database of client
> version strings to which it's safe to send the "hostkeys" global request.
> Otherwise, it can't send it because a bunch of half-baked clients (I'm
> counting 7 in our list) are borked and can't handle receiving a global
> request. Or they can handle it usually, but not when they're expecting a
> response to a channel open.
>
>
> Yeah, understood. So far, I haven’t implemented “hostkeys" support in
> AsyncSSH. I may do that at some point, but I’ll probably just do the new
> host key validation in AsyncSSH but leave it up to the application code to
> decide if it actually wants to update the list of known_hosts or not (and
> if so, where). Right now, AsyncSSH will read from ~/.ssh/known_hosts by
> default if you don’t specify another source, but it never actually modifies
> that file. In fact, most of the ways of specifying known_hosts in AsyncSSH
> are focused on providing the set of hosts dynamically, or even allowing
> applications to provide their own logic to determine whether a specific
> host key should be trusted or not for a given host/port, so I’d want to do
> the same thing with reporting new host keys a server advertises.
>
> Since I don’t have this support yet, I haven’t needed to worry about which
> clients can properly handle global requests or not. I do use global
> requests in both directions as part of the implementation of "
> keepalive@openssh.com”, but so far I haven’t run into any issues with
> that. That’s disabled by default, though, so perhaps people are only
> enabling with peers that don’t have issues with global requests.
>
>
> Meanwhile I've received more info about the implementation that
> disconnects on receiving EXT_INFO from the client. The bug is unfortunately
> in a widely used Java SSH library. The information I received suggests it's
> going to be fixed, but I'm afraid there are already a fair number of
> deployed servers that have the issue.
>
>
> Interesting. Does it fail on ANY global request being sent from a server,
> or is it only at certain points that it doesn’t handle these messages
> correctly?
>
>
> While I'm wishing things - I would also like the "delay-compression"
> extension to be more widely supported because it's the only
> delayed-compression mechanism that (1) does not have a race condition by
> design (zlib@openssh.com), and (2) does not require a second key exchange
> after user authentication (PuTTY mitigation).
>
>
> Is RFC 8308 the right reference for this option? Are there any
> implementations of this so far other than from Bitvise?
>
> Also, I’m not familiar with the PuTTY issue around needing a second key
> exchange. Is that documented somewhere?
> --
> Ron Frederick
> ronf@timeheart.net
>
>
>
>