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

denis bider <> Mon, 27 April 2020 05:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 996B23A0C5B for <>; Sun, 26 Apr 2020 22:34:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cO0gv6HVohFj for <>; Sun, 26 Apr 2020 22:33:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EA0073A0C5C for <>; Sun, 26 Apr 2020 22:33:58 -0700 (PDT)
Received: by with SMTP id z17so24238269oto.4 for <>; Sun, 26 Apr 2020 22:33:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7k1mgKvfl5iabHPq2T7C35xiLFmq4/R2h8oQ4ZPrZOM=; b=oZRygU078wGLaumXfULNhVLdehu3KQjwhkkYLQdHAjvjapYj1sO9eB77/DwBTjpLEl Lp5RWAzxo8JOQhWxNWIvAS2xbUb2D9HPHuXM3ghp/SgpnCCRhfXvZLhX58XZuDczcERC N18sD3OdHjebT03hDxTBRohycZvoDbux6G7bVg2u8r6uvIO/EGdHqgEEitzgtY529hJy OJYocHE3rTdD888QY2rIooGWyDe6bL03ebarcoewZbDyM0EkrgHUke/cel/na54bE1ve EldlSN+cDlIRQYDp1JBWsi831YgXffTLPN7mQT9v+sX3ERVfPxTcy8pWpd2OheaTWAkf YsEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7k1mgKvfl5iabHPq2T7C35xiLFmq4/R2h8oQ4ZPrZOM=; b=NnMc+/thuDqKAZ6w5eco/MgEqi6PnL76Jnl3K9erCJD/2sr2uMAsAPe8SnZWHNmSgu KRXYiuEDPgFf1OOZ3YtPKItHZsHVtZrZtHwTnFvjVOwzKt48hilUrT49gULzjs7UQd8G oR3dbZUfa8feeI0J3Vz6ROX+eIIkXDTTJOfDmOeIP9RvvbwuJCUA7gzf214ZVMqrAdk8 4p8A8DR+3qvltqUz7/y1AAf6E8MgjUu82NldN7nhNjvuD9q/c0B65hfijuC4Wgrep7xY OsoFUnzQzCULXlzKM5GXeTKmENo+5dzEwvWogvlhbdS19z0jkIX+a0pD//6f2lG81d8c 6dfA==
X-Gm-Message-State: AGi0Pua+6eIzx4jftqPOgeNyLj8Uvzgb36m6R+mE4BDORKlPKg9hho33 tLWjeTeT31C2URfqJA1G3QKAir3IKZGrOJZXogc=
X-Google-Smtp-Source: APiQypIl800AYdaxIyf2U3jkVy/feLPDL9jXk9mUKotCTWL+cDn0QXBbnYx72+8J4HMPdlgbuITwQSnVW7kWkUhi97Q=
X-Received: by 2002:a9d:874:: with SMTP id 107mr17075779oty.220.1587965637978; Sun, 26 Apr 2020 22:33:57 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: denis bider <>
Date: Mon, 27 Apr 2020 00:33:46 -0500
Message-ID: <>
To: Ron Frederick <>
Cc: curdle <>,, Damien Miller <>
Content-Type: multipart/alternative; boundary="000000000000c46f1f05a43f0f34"
Archived-At: <>
Subject: Re: [Curdle] Client-side SSH_MSG_EXT_INFO: Use it or lose it principle!
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of potential new security area wg." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Apr 2020 05:34:02 -0000


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 "" after user authentication:

This is essential functionality which allows clients and servers to change
host keys without requiring administrative intervention at each client

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.

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.

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 (, and (2) does not require a second key exchange
after user authentication (PuTTY mitigation).


On Sun, Apr 26, 2020 at 12:33 PM Ron Frederick <> wrote:

> Hi Denis,
> On Apr 26, 2020, at 5:03 AM, denis bider <>
> wrote:
> it has come to my attention that at least one SSH server implementation
> (a) advertises support for SSH_MSG_EXT_INFO as defined in RFC 8308, and (b)
> disconnects on actual receipt of an EXT_INFO message from the client.
> This happens when we define a general mechanism, but then the most widely
> used implementations only use certain aspects of it. Lots of
> implementations now support EXT_INFO sent by the server because it's needed
> for RSA-SHA2 signatures, but only a handful implementations send EXT_INFO
> by the client.
> Bitvise SSH Client sends EXT_INFO if the server supports it. It's free to
> use or test with - but it runs on Windows and lots of people don't want to
> test with that.
> It's possible that your implementation has no need for any of the
> extensions that would appear in EXT_INFO from the client. However, if you
> wish for this extensibility to be available in the future, then if your
> client supports EXT_INFO, I would strongly suggest that it sends it.
> If you want to send a client-side EXT_INFO that takes minimal effort, I
> suggest:
> 1. Ensure that your SSH client can correctly handle SSH_MSG_GLOBAL_REQUEST
> received at any point. Your client should not disconnect when it receives
> this message, or act like it received a channel open failure if it receives
> a global request when it's waiting for a channel open confirmation. These
> are the two most common error modes relating to global requests.
> 2. Once you have ensured the above, if the server supports EXT_INFO, send
> a client-side EXT_INFO implementing the extension "global-requests-ok" as
> defined in this draft:
> This tells the server that your client properly implements global requests
> so that the server can use them for things like active keep-alives.
> Implementing this would take minimal effort and would help ensure that
> client-side EXT_INFO remains an available extension mechanism 10 years down
> the road for SSH.
> I’ve made this change in the AsyncSSH “develop” branch as commit
>, and will roll this into
> the next release. Most of the support was already in place as I already had
> common code for generating and parsing EXT_INFO on both the client and
> server. The changes are as follows:
>     - AsyncSSH now advertises that it will accept EXT_INFO from clients
> when acting as a server
>     - AsyncSSH will send the global-requests-ok extension when acting as a
> client and talking to a server that supports EXT_INFO from clients
> Since AsyncSSH doesn’t actually have any heuristics around disabling the
> use of global requests based on client software/version, it doesn’t
> actually do anything right now when it receives the ‘global-requests-ok’
> extension. However, I confirmed it successfully parses received extensions,
> so it should be easy to process future extensions from the client when this
> is needed.
> I also specifically tested this against the Bitvise server (thanks for
> making that available for free for non-commercial use!), and it seems to
> work well.
> --
> Ron Frederick