From owner-freebsd-security@freebsd.org Sun Sep 12 16:31:15 2021 Return-Path: Delivered-To: freebsd-security@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3C663668E2E for ; Sun, 12 Sep 2021 16:31:15 +0000 (UTC) (envelope-from bilbo@hobbiton.org) Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H6w8y3H3pz3mSL for ; Sun, 12 Sep 2021 16:31:14 +0000 (UTC) (envelope-from bilbo@hobbiton.org) Received: by mail-ej1-x62b.google.com with SMTP id o20so4894316ejd.7 for ; Sun, 12 Sep 2021 09:31:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ofwilsoncreek-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x3RWBhegd22M/bhE4I1kEWFHEJnhTVDsJei93OLZRwo=; b=sdCtuLmkcBCMRuILYZCXyiNfYwB8nahmgcTx/8gM43qTY0AHu4FsOC+dwRV3nuW7EC G6Kp6wM2qfFMY1A/RgtPPwpRs4XIEvxD4gMn75Tmd7GCOuBCSMxLunXGCsUMaBPtxOu9 Z05i4vrI5ds6gDR5uZh6RPNGjQO70t+yQAvYtEA/os+LQ8vJtwAh4GDfqOv+PDQWrbqn T47iT0OpUHARIDwrlKMXy82QIJBGfcEy0eicF0jrs4kfO2+MOFbMip1/34GyzlDeCSDs aEExsImH4lXZUXNILOdMRSVr+Ll/ZB/JgF8hctrgUPZOhjQ6T71THquaJufwoDSAgSm0 61PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x3RWBhegd22M/bhE4I1kEWFHEJnhTVDsJei93OLZRwo=; b=G49bVwH2EEmtx+oWwlXa2GlIv4pqJaZdreBSW5jgFgrR0fhQaXIEyND+wIPJS+DeLA wx0gn5fVByDVvFW9x0Y7x7BeGWLileTcYS3kOMDo6+Mk5Nku2/FnxvrXTgpGdPYYPkF/ k8pytzyeWHDtrLyOrbtN5Oo+YKx+rwqFkb80WfLvwEs9vClMobrvTrhFWW0qFbX5Fn9E AhEhpEqxYdpEgcZPBWopBt6QzoD4tVDrQ9njLhFRX6ASG7irFUmYmwi2Ja4OBX76t1Tq qPzfJZ3wwgl4VVtY4alnHGH8IrwEXho6bydWeND95Al4lDm+4veic10OOpmnPS0OQCO0 I0Ag== X-Gm-Message-State: AOAM5314Y0wF5wDHQXRp0hbpGlkoDRIasD5DlpENKKf91N91bXLDILF9 SQw5+UA9PHJZXflTOxUlerBumgDYyf1U90VVFZM4x8cCafE= X-Google-Smtp-Source: ABdhPJwCRMn6NL66vYkCEF35WXQNssO6QQf63wq+z/iLhnGpe9CJXSUA+HHGUJIjdk2VfxUPaepXBzzmzfiT9cuf72E= X-Received: by 2002:a17:906:ca1:: with SMTP id k1mr8172373ejh.369.1631464272514; Sun, 12 Sep 2021 09:31:12 -0700 (PDT) MIME-Version: 1.0 References: <8169A4A8-B8D1-4265-87C8-74ED4D34FBC8@fasel.at> <2bb56783-2727-9bea-7810-58969d91c00f@denninger.net> In-Reply-To: <2bb56783-2727-9bea-7810-58969d91c00f@denninger.net> From: Leif Pedersen Date: Sun, 12 Sep 2021 11:30:36 -0500 Message-ID: Subject: Re: Important note for future FreeBSD base system OpenSSH update To: freebsd-security@freebsd.org Cc: Karl Denninger X-Rspamd-Queue-Id: 4H6w8y3H3pz3mSL X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ofwilsoncreek-com.20150623.gappssmtp.com header.s=20150623 header.b=sdCtuLmk; dmarc=none; spf=pass (mx1.freebsd.org: domain of bilbo@hobbiton.org designates 2a00:1450:4864:20::62b as permitted sender) smtp.mailfrom=bilbo@hobbiton.org X-Spamd-Result: default: False [-1.20 / 15.00]; ARC_NA(0.00)[]; MAILMAN_DEST(0.00)[freebsd-security]; R_DKIM_ALLOW(-0.20)[ofwilsoncreek-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org]; DMARC_NA(0.00)[ofwilsoncreek.com]; NEURAL_SPAM_SHORT(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[ofwilsoncreek-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62b:from]; FORGED_SENDER(0.30)[leif@ofwilsoncreek.com,bilbo@hobbiton.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; FROM_NEQ_ENVFROM(0.00)[leif@ofwilsoncreek.com,bilbo@hobbiton.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2021 16:31:15 -0000 I agree with Karl. To further the point: "Secure by default" is a good idea, so removing ssh-rsa from the default list makes sense to alert people if its still in use. Management ports for power strips, switches, UPSs, generators, thermostats, radios, etc should already be isolated on a separate vlan or whatever. If they're not, they're not secure anyway, regardless of the crypto algorithms because nearly all of their stacks have known security holes now anyway. Taking away ssh-rsa is not necessary or helpful for improving anything's security. The only tactic for maintaining this older equipment is to keep an old installation of FreeBSD in service past its support period on an intermediate host. True, one can cherry-pick an old version of OpenSSH form the old Ports tree, but the ports tree improves and drops support for building old versions, as do the compilers. Over a 10-year time horizon, building an old version will become unsustainable without an old installation of FreeBSD. Some of us will recall that this is already the answer for connecting to hardware that only supports SSH1. I understand removing SSH1 more; I can imagine it was more effort to keep up support for that being a different protocol, etc, but ssh-rsa seems much simpler. However thinking longer term as this situation evolves and OpenSSH continues adding new and removing old support, the future of OpenSSH will also become unable to connect to these intermediate hosts, requiring yet another intermediate host running a frozen-in-time version of FreeBSD. And eventually the replacement hardware for these becomes an issue. All of this requires an insane amount of customization and time investment for individual shops, when it could be solved by keeping ssh-rsa available as part of the core project, and simply omit it from the default list. Granted, I'm not one to speak credibly on the level of effort required for this, nor is it necessary to convince me for FreeBSD to make a decision. However as an educated observer, it appears to be easy enough to keep support for ssh-rsa more or less forever, even to the point where its only utility is to connect to hardware in museums. -Leif On Sun, Sep 12, 2021, 9:41 AM Karl Denninger wrote: > On 9/12/2021 10:02, Markus Falb wrote: > >> On 09.09.2021, at 20:01, Ed Maste wrote: > >> > >> OpenSSH will disable the ssh-rsa signature scheme by default in the > >> next release. > >> > >> ... > >> > >> To check whether a server is using the weak ssh-rsa public key > >> algorithm, for host authentication, try to connect to it after > >> removing the ssh-rsa algorithm from ssh(1)'s allowed list: > >> > >> ssh -oHostKeyAlgorithms=-ssh-rsa user@host > > FWIW, some of us may already have dealt with that. > > FIPS enabled RedHat Enterprise Linux (and probably other FIPS enabled > > systems) means effectively no ssh-rsa signature available in the sshd. > > I had that situation at the beginning of the year. > > > > As mentioned, ssh-rsa signature algorithm will stop working, but > > that does not automatically imply that every RSA key must be > > changed to something other. The signature algorithm is not a > > property that is inherent to the key. > > > > That said, existing RSA keys were working fine for me (my openssh > > client was rsa-sha2-256 and rsa-sha2-512 capable) but when I tested > > with some popular windows clients (filezilla, putty) it failed > > (apparently no rsa-sha2 algorithms available). > > > > I found it interesting that mentioned clients were ecdsa > > capable but did not support sha2 signatures with RSA keys. > > Maybe the situation changed in the meantime to the better. > > > > There are 3 scenarios: > > > > 1. both sides support rsa-sha2 signatures -> RSA keys still working > > > > 2. one side does not support sha2 signatures but does support other > > key types -> you can change key type > > > > 3. one side does not support sha2 and no other key type -> you loose > > > > A prominent candidate for 3. would be Cisco IOS > > This has come up before with web browsers and is a serious PITA when > there is no override available for those who need it on a targeted, > specific basis. > > I have in the field a BUNCH of "smart" rack power strips that have this > problem; their management firmware does NOT support more-modern cipher > sets and SSL requirements. I get it, those older SSL versions are > insecure and we know it. But when the browser people all decided to > kill the ability to connect to such servers with no override (that is, > don't warn, DENY with no option to get around it) all of a sudden > logging into those strips to change (for example) the name of a socket, > the alarm limits and similar became literally impossible. Contacting > the manufacturer resulted in a middle finger back; "nope, we're not > releasing new firmware for that." I've seen the same thing with some > older OOB management interfaces on server boards; they won't take an > acceptably-long (by modern standards) HTTPS server key, and thus, same > problem and same answer from the manufacturer. These are > perfectly-serviceable devices in their application and quite-expensive > to replace when there's nothing wrong with them. On the server boards by > now they've all been retired as people decided the better power budget > and performance levels made changing them (and re-purchasing the RAM > that went on them, which for larger servers is a non-trivial part of the > total expense) a reasonable proposition. This of course is not true for > a smart power strip in the rack and makes both monitoring of energy and > remote-hard-power-cycle available without a physical site visit or > remote hands. > > In the case of the power strips the "answer" was one of the prepackaged, > self-contained old "portable" versions of FireFox which complains but > the alert can be clicked through. I recognize that exposing those > devices to the Internet is unsafe but have never trusted that anyway; > they're behind a gateway box with no port hole punch and if I'm VPN'd in > then it's not possible for a random person to screw with it. > > It would be sad indeed if the only answer here is "load up a partition > with an older copy of FreeBSD on some device and use that." Can we > avoid that being the answer, as it became with the browser issues? > > -- > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ >