From owner-freebsd-security@freebsd.org Sun Sep 12 14:02:56 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 13E83666AA4 for ; Sun, 12 Sep 2021 14:02:56 +0000 (UTC) (envelope-from markus.falb@fasel.at) Received: from uruz.anode.at (uruz.anode.at [188.40.148.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H6rsp73CFz4ptH for ; Sun, 12 Sep 2021 14:02:54 +0000 (UTC) (envelope-from markus.falb@fasel.at) Received: from 84-113-78-5.cable.dynamic.surfer.at ([84.113.78.5]:34065 helo=dwalin.fasel.at) by uruz.anode.at with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_2) (envelope-from ) id 1mPQ4E-0007yT-RC for freebsd-security@freebsd.org; Sun, 12 Sep 2021 16:02:47 +0200 Received: from winch.fasel.at ([10.10.10.10]:55958) by dwalin.fasel.at with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_2) (envelope-from ) id 1mPQ4F-0005Rk-IN for freebsd-security@freebsd.org; Sun, 12 Sep 2021 16:02:47 +0200 Received: from [10.12.10.2] by winch.fasel.at with esmtp (Exim 4.67) (envelope-from ) id 1mPQ4E-0002PR-E0 for freebsd-security@freebsd.org; Sun, 12 Sep 2021 16:02:46 +0200 From: Markus Falb Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: Important note for future FreeBSD base system OpenSSH update Date: Sun, 12 Sep 2021 16:02:42 +0200 References: To: freebsd-security@freebsd.org In-Reply-To: Message-Id: <8169A4A8-B8D1-4265-87C8-74ED4D34FBC8@fasel.at> X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Spam-Score: 0.0 (/) X-Spam-Report: Scored with 0.0 by uruz.anode.at, TVD_RCVD_IP=0.001 X-Rspamd-Queue-Id: 4H6rsp73CFz4ptH X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of markus.falb@fasel.at has no SPF policy when checking 188.40.148.130) smtp.mailfrom=markus.falb@fasel.at X-Spamd-Result: default: False [-1.60 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[fasel.at]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[4]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:188.40.0.0/16, country:DE]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-security]; RECEIVED_SPAMHAUS_PBL(0.00)[84.113.78.5:received] 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 14:02:56 -0000 > 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 Best Regards, Markus From owner-freebsd-security@freebsd.org Sun Sep 12 14:40:58 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 636F3666DE2 for ; Sun, 12 Sep 2021 14:40:58 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H6sjj2w04z513B for ; Sun, 12 Sep 2021 14:40:57 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (096-033-205-208.res.spectrum.com [96.33.205.208]) by colo1.denninger.net (Postfix) with ESMTP id 2D9D4211089 for ; Sun, 12 Sep 2021 10:40:50 -0400 (EDT) Received: from [192.168.10.25] (D15.Denninger.Net [192.168.10.25]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 8B2952EC9C0 for ; Sun, 12 Sep 2021 10:40:50 -0400 (EDT) Subject: Re: Important note for future FreeBSD base system OpenSSH update To: freebsd-security@freebsd.org References: <8169A4A8-B8D1-4265-87C8-74ED4D34FBC8@fasel.at> From: Karl Denninger Message-ID: <2bb56783-2727-9bea-7810-58969d91c00f@denninger.net> Date: Sun, 12 Sep 2021 10:40:49 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <8169A4A8-B8D1-4265-87C8-74ED4D34FBC8@fasel.at> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms070404000009040207020201" X-Rspamd-Queue-Id: 4H6sjj2w04z513B X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=denninger.net; spf=pass (mx1.freebsd.org: domain of karl@denninger.net designates 104.236.120.189 as permitted sender) smtp.mailfrom=karl@denninger.net X-Spamd-Result: default: False [-5.90 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[karl]; FROM_HAS_DN(0.00)[]; SIGNED_SMIME(-2.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; HAS_ATTACHMENT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_NONE(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_SHORT(-1.00)[-0.997]; DMARC_POLICY_ALLOW(-0.50)[denninger.net,none]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; ASN(0.00)[asn:14061, ipnet:104.236.64.0/18, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-security] 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 14:40:58 -0000 This is a cryptographically signed message in MIME format. --------------ms070404000009040207020201 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable 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=3D-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=20 there is no override available for those who need it on a targeted,=20 specific basis. I have in the field a BUNCH of "smart" rack power strips that have this=20 problem; their management firmware does NOT support more-modern cipher=20 sets and SSL requirements.=C2=A0 I get it, those older SSL versions are=20 insecure and we know it.=C2=A0 But when the browser people all decided to= =20 kill the ability to connect to such servers with no override (that is,=20 don't warn, DENY with no option to get around it) all of a sudden=20 logging into those strips to change (for example) the name of a socket,=20 the alarm limits and similar became literally impossible.=C2=A0 Contactin= g=20 the manufacturer resulted in a middle finger back; "nope, we're not=20 releasing new firmware for that."=C2=A0 I've seen the same thing with som= e=20 older OOB management interfaces on server boards; they won't take an=20 acceptably-long (by modern standards) HTTPS server key, and thus, same=20 problem and same answer from the manufacturer.=C2=A0 These are=20 perfectly-serviceable devices in their application and quite-expensive=20 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=20 and performance levels made changing them (and re-purchasing the RAM=20 that went on them, which for larger servers is a non-trivial part of the = total expense) a reasonable proposition.=C2=A0 This of course is not true= for=20 a smart power strip in the rack and makes both monitoring of energy and=20 remote-hard-power-cycle available without a physical site visit or=20 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=20 the alert can be clicked through.=C2=A0 I recognize that exposing those=20 devices to the Internet is unsafe but have never trusted that anyway;=20 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=20 with an older copy of FreeBSD on some device and use that."=C2=A0 Can we = avoid that being the answer, as it became with the browser issues? --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms070404000009040207020201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjEwOTEyMTQ0MDUw WjBPBgkqhkiG9w0BCQQxQgRAgcz3pFGx3UALnlyUS9o4FIuVAm11G9QZhTv8c+mcQDY02BIi 8nCb5OgEA+B3qLab/vIkKXM1/oY7ASmA5nO7PjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgCXEELDb0qwXkZOD07om/xPG7yowgC0OFoTeiSrAblYgSboZx9GrNSiF/LntWs1n/1h xi/1jvdR3Lz+dGE9QktGRyfXKE3bohhwD2qGnNYNk1K0ba5uv8s6OLHTY145z/Cye6VwWS0z MYjA9AxjBQ139qCLgUKeSzvlrIXbwkhg+gnlJGhm4vvQPtbf5bDjGEDf/5guOM6fvMI4fWGk 1wArIgLO0lrj/c5Ix3LGicWBN9UXYeMZBUnnH9Kcqv4hKDh9DyfPIPBqhr3vaijIFtaVi2mc MdLtpybLGg2i/XIyjeLRwS5WOCrZ3lIEg3gP41urUVHMoVYgZ58aRKGvvjF3LHaXxq4fP7yj XdlnzGHUCUUCVwjd2WqyMmn/A6PwhAL+sUpiiR0gs681hZbKjRHy2Cpnz2YtBCIzwA8jjRx9 4Yxp/Pc38kACXm/FOXZLGmrQOgZFS21fgY5IYq8VKaeAUYORMl250a5TT6AtvnArWqqD/jgr yi6fvHPbxJsBjItuLW0BIgAtfFTdi7KucvMLhZx4DyvXFjxvEmun00VaJETJi2LnyGgchKP2 CbMLpJ2hL3F2lVwnNjTux/26O7/K9Xtpqt7qZ/GAhNvYN3ELCyGuNl79r9pvmyIUXXWfkGh1 uMCzZ8H1gP6AfgzY1COP1DMv3s7DnfFgrs+o0JbQvgAAAAAAAA== --------------ms070404000009040207020201-- 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]/ > From owner-freebsd-security@freebsd.org Sun Sep 12 19:45:13 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 06CAF66C757 for ; Sun, 12 Sep 2021 19:45:13 +0000 (UTC) (envelope-from news@mips.inka.de) Received: from mail.inka.de (mail.inka.de [IPv6:2a04:c9c7:0:1073:217:a4ff:fe3b:e77c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H70Sm0Dzjz3NrF for ; Sun, 12 Sep 2021 19:45:11 +0000 (UTC) (envelope-from news@mips.inka.de) Received: from mips.inka.de (news@[127.0.0.1]) by mail.inka.de with uucp (rmailwrap 0.5) id 1mPVPU-008pj9-DX; Sun, 12 Sep 2021 21:45:04 +0200 Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.16.1/8.16.1) with ESMTP id 18CJemol053623 for ; Sun, 12 Sep 2021 21:40:48 +0200 (CEST) (envelope-from news@lorvorc.mips.inka.de) Received: (from news@localhost) by lorvorc.mips.inka.de (8.16.1/8.16.1/Submit) id 18CJemDg053622 for freebsd-security@freebsd.org; Sun, 12 Sep 2021 21:40:48 +0200 (CEST) (envelope-from news) To: freebsd-security@freebsd.org From: Christian Weisgerber Newsgroups: list.freebsd.security Subject: Re: Important note for future FreeBSD base system OpenSSH update Date: Sun, 12 Sep 2021 19:40:48 -0000 (UTC) Message-ID: References: <8169A4A8-B8D1-4265-87C8-74ED4D34FBC8@fasel.at> <2bb56783-2727-9bea-7810-58969d91c00f@denninger.net> User-Agent: slrn/1.0.3 (FreeBSD) X-Rspamd-Queue-Id: 4H70Sm0Dzjz3NrF X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of news@mips.inka.de has no SPF policy when checking 2a04:c9c7:0:1073:217:a4ff:fe3b:e77c) smtp.mailfrom=news@mips.inka.de X-Spamd-Result: default: False [-1.80 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[news]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_NA(0.00)[inka.de]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[naddy@mips.inka.de,news@mips.inka.de]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:202113, ipnet:2a04:c9c7::/32, country:DE]; FROM_NEQ_ENVFROM(0.00)[naddy@mips.inka.de,news@mips.inka.de]; MAILMAN_DEST(0.00)[freebsd-security] 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 19:45:13 -0000 On 2021-09-12, Leif Pedersen wrote: > Management ports for power strips, switches, UPSs, generators, thermostats, > radios, etc should already be isolated on a separate vlan or whatever. In which case you can just use telnet(1). -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-security@freebsd.org Sun Sep 12 20:30:37 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 9CB2E66D4E5 for ; Sun, 12 Sep 2021 20:30:37 +0000 (UTC) (envelope-from bilbo@hobbiton.org) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 4H71T82t1Tz3ryd for ; Sun, 12 Sep 2021 20:30:36 +0000 (UTC) (envelope-from bilbo@hobbiton.org) Received: by mail-ed1-x52b.google.com with SMTP id t6so9698213edi.9 for ; Sun, 12 Sep 2021 13:30:36 -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=Zp3Qa+QdAVvN5rNlgHRbHBEtgfVbLg6mAk/fL0BW0ls=; b=hP0/Z/MLC5wbtXDWumijUvipiEt0vzZqpeTr8GrO/48GB0MzQW/pUF9PCx/cBiKSED DMYqno7ZEMeebcXDSHvS3l/eMcoXZDu7tC4ZiNVRar4SxH0tT0nuN0KdfkNO8esFoOyf GNRo0svx1QkhteGetYHEjbDcPGYa/5fY2urOkkyRQbPiVnLOHQcDF2OaPVs2YzqyTSO/ +ayfjxHcOiVJubW4iJ2TCgTq1TWbnP3rkpaj6A1KlGMd0KJrq1fvDpOnmBz660a2aHcT fzsWfQQJLdj1GaTHzLCksfU8L5A/hlPNByNueIlKZk4r+ob2RrBLWi19OhWHQSG9LxCl YY8g== 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=Zp3Qa+QdAVvN5rNlgHRbHBEtgfVbLg6mAk/fL0BW0ls=; b=MUjvTBA6URm2WcwyH0RH2OyO3q1TyNgvQtf2UUM17aUMse44mR19EfsxKfkJFKz8pm G8YPD6RBLCLubKtha9qdnQbdRGpG68s4FtnThxVRvwHIPKhRMJlOVUSMruUVbWRt3aK4 KJF4cf3vP0QPHL0zZnnyXJRwXRTfaj/rM0PUIUb4z7jXmFln1ZreqjTka2IIZ10c+xNM 4ejnaCGiF+eleBR+xzJL/sUh6S3kCWwPXLw7PwO1bbHkfx5hp/lU7FEdzunf/fGYTIOW 6YgOfin9cI7kEHvGSxP7PFOMVcUihdHMYI6BukHVozYcuXc4t2BgTDpW/0mPIUysEqze 3CVQ== X-Gm-Message-State: AOAM533QgRO/EtMCEh+DdNlSRbqxRCssbY2gf57mRQmKy1dqZab8gxsF 8ilVn7WRSpbxN1FbIql2udNCmtbj2bz93hBZm3UTlrCaPWM= X-Google-Smtp-Source: ABdhPJyw1lrQrZ1J3RLxZXAMt/RNDmK11tvzBfcwlIU3/7DhFWpE/yeIX7wMzcC7lPPAYGDKadMF0Hhz4S5sk4tEcog= X-Received: by 2002:a05:6402:31eb:: with SMTP id dy11mr9885994edb.17.1631478635289; Sun, 12 Sep 2021 13:30:35 -0700 (PDT) MIME-Version: 1.0 References: <8169A4A8-B8D1-4265-87C8-74ED4D34FBC8@fasel.at> <2bb56783-2727-9bea-7810-58969d91c00f@denninger.net> In-Reply-To: From: Leif Pedersen Date: Sun, 12 Sep 2021 15:30:23 -0500 Message-ID: Subject: Re: Important note for future FreeBSD base system OpenSSH update To: Christian Weisgerber Cc: freebsd-security@freebsd.org X-Rspamd-Queue-Id: 4H71T82t1Tz3ryd X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ofwilsoncreek-com.20150623.gappssmtp.com header.s=20150623 header.b="hP0/Z/ML"; dmarc=none; spf=pass (mx1.freebsd.org: domain of bilbo@hobbiton.org designates 2a00:1450:4864:20::52b as permitted sender) smtp.mailfrom=bilbo@hobbiton.org X-Spamd-Result: default: False [-3.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]; 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::52b:from]; NEURAL_HAM_SHORT(-1.00)[-0.999]; 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 20:30:37 -0000 On Sun, Sep 12, 2021, 2:45 PM Christian Weisgerber wrote: > On 2021-09-12, Leif Pedersen wrote: > > > Management ports for power strips, switches, UPSs, generators, > thermostats, > > radios, etc should already be isolated on a separate vlan or whatever. > > In which case you can just use telnet(1). > Many devices offer only ssh. From owner-freebsd-security@freebsd.org Sun Sep 12 20:32:51 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 59FA666D3E0 for ; Sun, 12 Sep 2021 20:32:51 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from mx1.enfer-du-nord.net (mx1.enfer-du-nord.net [91.121.41.56]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H71Wk3DLKz3tDW for ; Sun, 12 Sep 2021 20:32:50 +0000 (UTC) (envelope-from trashcan@ellael.org) Received: from smtpclient.apple (x59cc8285.dyn.telefonica.de [89.204.130.133]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.enfer-du-nord.net (Postfix) with ESMTPSA id 4H71Wb0ygfzD3D for ; Sun, 12 Sep 2021 22:32:43 +0200 (CEST) From: Michael Grimm Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Important note for future FreeBSD base system OpenSSH update Date: Sun, 12 Sep 2021 22:32:42 +0200 References: <8169A4A8-B8D1-4265-87C8-74ED4D34FBC8@fasel.at> <2bb56783-2727-9bea-7810-58969d91c00f@denninger.net> To: freebsd-security@freebsd.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4H71Wk3DLKz3tDW X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.37 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[ellael.org:s=dkim]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; ARC_NA(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:91.121.41.56]; DKIM_TRACE(0.00)[ellael.org:+]; DMARC_POLICY_ALLOW(-0.50)[ellael.org,quarantine]; NEURAL_HAM_SHORT(-0.87)[-0.868]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16276, ipnet:91.121.0.0/16, country:FR]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-security]; RECEIVED_SPAMHAUS_PBL(0.00)[89.204.130.133:received] 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 20:32:51 -0000 Leif Pedersen wrote > "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. Very much: ACK Regards, Michael From owner-freebsd-security@freebsd.org Sun Sep 12 21:27:20 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 8CE7166E252 for ; Sun, 12 Sep 2021 21:27:20 +0000 (UTC) (envelope-from gordon@tetlows.org) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 4H72kb3BYcz4hl1 for ; Sun, 12 Sep 2021 21:27:19 +0000 (UTC) (envelope-from gordon@tetlows.org) Received: by mail-pf1-x432.google.com with SMTP id e16so6996167pfc.6 for ; Sun, 12 Sep 2021 14:27:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=uABA/R0eYBddfZx9MF/oeRYIPq0PTwyel6Yz/6K9v1o=; b=dyvNemH6J7HLueJA48+tRRFNBJfLlJjMY0jFb5WPSzjzVt8E4hSU+J/EXpf8hoIKis tq3i3qfDuxdqWyqDT/8FRT/lgn2PrXvPb8WMjv5a/CedK5hzbldBea4mVoFxXj1ikZgG GCumTCcZPZGvG1MBitNMVfFS3xE6BrmUfxIhkCFooy7VtvCFxZOgzZ35AWJTmnOHWysm vkP0EYlcJFjbvWMjQlZ8HC3VA9Euk9h+C9x/tEU+Ocu00PDsluf26XOAIDv9b38YgXgG noNmiKy0ocx2Ys5bRnkoZEvA8i1l/5wh5ZPNIcRpoqjWLrYU6dHuKTrwmzp0QRpJ+/Ww 35pA== X-Gm-Message-State: AOAM533zEecGhHgEgSo41JqdVDhrd8YdBoi2L+xgcDd8inc/3ouu82C9 89F8S26LPdKZfxk12QNdA/Wi9lIk7f1D X-Google-Smtp-Source: ABdhPJwXh5acxtRTEKUg2b1sf7fs7Nq9yVek6Ytgk6EQIyqw54aagCgjOQAS1crO9XlC17g8W2O2UQ== X-Received: by 2002:a63:8c1d:: with SMTP id m29mr8056475pgd.457.1631482038140; Sun, 12 Sep 2021 14:27:18 -0700 (PDT) Received: from smtpclient.apple (2603-8001-5e40-d300-196d-ea4a-7c26-49e7.res6.spectrum.com. [2603:8001:5e40:d300:196d:ea4a:7c26:49e7]) by smtp.gmail.com with ESMTPSA id m28sm5578213pgl.9.2021.09.12.14.27.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Sep 2021 14:27:17 -0700 (PDT) From: Gordon Tetlow Message-Id: Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: Important note for future FreeBSD base system OpenSSH update Date: Sun, 12 Sep 2021 14:27:16 -0700 In-Reply-To: <2bb56783-2727-9bea-7810-58969d91c00f@denninger.net> Cc: freebsd-security@freebsd.org To: Karl Denninger References: <8169A4A8-B8D1-4265-87C8-74ED4D34FBC8@fasel.at> <2bb56783-2727-9bea-7810-58969d91c00f@denninger.net> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4H72kb3BYcz4hl1 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[tetlows.org:s=google]; FREEFALL_USER(0.00)[gordon]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[tetlows.org:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::432:from]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[tetlows.org,quarantine]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-security] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 21:27:20 -0000 > On Sep 12, 2021, at 7:40 AM, Karl Denninger = wrote: >=20 > 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. Blaming the browser and other client providers (OpenSSH, etc) for a = problem that is 100% because the devices are now abandoned by the = manufacturer is the wrong place to focus your anger. We have an enormous = problem in the industry of crappy embedded devices (like the OOB = management plane) accruing technical security debt while the = manufacturers give "a middle finger back" as you say. The supportability = of the hardware needs to be baked into the purchasing decision. = Commitments from the manufacturers on supportability timeframes are = important to understand and budget into a hardware refresh cycle. > 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. >=20 > 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? You are already accepting the risk of continuing to run devices with = known bad configurations. What's the problem with keeping that old = FreeBSD host around as well, it's just one more risk acceptance for = issues that are pretty much the same as what you are already accepting? = Alternatively, compile and install an older OpenSSH version on = well-maintained host in a dedicated prefix which is only used for that = purpose. We do need to remove the code entirely as putting it behind a = compatibility or some other "scary things are here" flag will guarantee = that manufacturers don't try to update their codebases to work with = modern protocols; they will just provide instructions on how to enable = scary mode and move on. In the interest of protecting everyone, we need = to remove this code and put it into the dustbin of history. Best, Gordon= From owner-freebsd-security@freebsd.org Sun Sep 12 22:10:46 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 6932466F3EE for ; Sun, 12 Sep 2021 22:10:46 +0000 (UTC) (envelope-from dan@obluda.cz) Received: from smtp1.ms.mff.cuni.cz (smtp1.ms.mff.cuni.cz [IPv6:2001:718:1e03:801::4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "submission.mff.cuni.cz", Issuer "GEANT OV RSA CA 4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H73hj2Mmjz4sr7 for ; Sun, 12 Sep 2021 22:10:44 +0000 (UTC) (envelope-from dan@obluda.cz) X-SubmittedBy: id dan@mff.cuni.cz subject /postalCode=110+2000/O=Univerzita+20Karlova/street=Ovocn+5CxC3+5CxBD+20trh+20560/5/ST=Praha, +20Hlavn+5CxC3+5CxAD+20m+5CxC4+5Cx9Bsto/L=Praha+201/C=CZ/CN=Dan+20Luke+5CxC5+5CxA1/emailAddress=dan@mff.cuni.cz serial CD205F9D3D7CB4A48FB4D309D9790FA2 issued by /C=NL/O=GEANT+20Vereniging/CN=GEANT+20Personal+20CA+204 auth type TLS.CUNI DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=obluda.cz; s=mffsubmission; t=1631484635; x=1632784635; bh=qxpoRGY52oWGI2DVDr8BXWvbDSfVjRfhCR+8wik8C3c=; h=From:MIME-Version; b=NBLFtUM2fchni2xzRpKwD5YGpM7kBZtoPOJ88fOZlT27L57FCKHYfEYfD1Kx5L1hv MgFEA46ZZCNACbSr6GdBWagFtmM/Zs6eI8CYfDuUC9GsZ76ajgx7FYJsEocVNtaQJL M/xQDjHUbFi/4akyIa1HyDjG1ZXAeTgEB/RJtd+A6FbS3eNAu3LlyaF6SGpWjOQYW2 8B1+eFt3QTfw3j3Qo9Dqc7GlFpzwop21MoKRf6h4hu6EBnhgQ/35FyvVb4KJ4OLe8K 7k8YEd4Aj5cLyYc6fEd16Qf0zyQHDeBkQFaRXRkz24YX9MIYm0jznu7ptrrarcYTyu Ld20goEo5Jjvw== Received: from [10.46.29.2] ([194.108.204.138]) (authenticated) by smtp1.ms.mff.cuni.cz (8.16.1/8.16.1) with ESMTPS id 18CMAWCl058766 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK) for ; Mon, 13 Sep 2021 00:10:34 +0200 (CEST) (envelope-from dan@obluda.cz) Subject: Re: Important note for future FreeBSD base system OpenSSH update To: freebsd-security References: <8169A4A8-B8D1-4265-87C8-74ED4D34FBC8@fasel.at> <2bb56783-2727-9bea-7810-58969d91c00f@denninger.net> From: Dan Lukes Message-ID: <0c3a5f3c-fb07-fae3-22f3-28703c842deb@obluda.cz> Date: Mon, 13 Sep 2021 00:10:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 SeaMonkey/2.53.9 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4H73hj2Mmjz4sr7 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=obluda.cz header.s=mffsubmission header.b=NBLFtUM2; dmarc=pass (policy=none) header.from=obluda.cz; spf=none (mx1.freebsd.org: domain of dan@obluda.cz has no SPF policy when checking 2001:718:1e03:801::4) smtp.mailfrom=dan@obluda.cz X-Spamd-Result: default: False [-3.80 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[obluda.cz:s=mffsubmission]; FREEFALL_USER(0.00)[dan]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[obluda.cz:+]; DMARC_POLICY_ALLOW(-0.50)[obluda.cz,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2852, ipnet:2001:718::/32, country:CZ]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-security] 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 22:10:46 -0000 On 12.9.2021 23:27, Gordon Tetlow via freebsd-security wrote: > Blaming the browser and other client providers (OpenSSH, etc) for a=20 > problem that is 100% because the devices are now abandoned by the=20 > manufacturer is the wrong place to focus your anger. We have an=20 > enormous problem in the industry of crappy embedded devices (like the=20 > OOB management plane) accruing technical security debt while the=20 > manufacturers give "a middle finger back" as you say. The=20 > supportability of the hardware needs to be baked into the purchasing=20 > decision. Commitments from the manufacturers on supportability=20 > timeframes are important to understand and budget into a hardware=20 > refresh cycle. "One size fits all" may be acceptable approach for unskilled home users, = but not for professional use. The security mechanism may be secure=20 enough for particular use even if there are known issues with the method = in question. There may be a various reason to abandon particular method/algorithm but = don't claim it's for my security because it's just not true. If=20 particular algorithm is not secure enough for me I'm not using it=20 despite it's supported. If algorithm is the best for particular case=20 (it's why I'm using it) the removal will decrease overall security of=20 such system.=A0 In no case the security will be increased. We should avoid to make decisions on behalf of skilled security officer=20 familiar with particular use case. Just my $0,02 Dan From owner-freebsd-security@freebsd.org Sun Sep 12 22:45:21 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 E678967008B for ; Sun, 12 Sep 2021 22:45:21 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 4H74Sc72GXz3Jcg for ; Sun, 12 Sep 2021 22:45:20 +0000 (UTC) (envelope-from tomek@cedro.info) Received: by mail-oi1-x235.google.com with SMTP id n27so11736691oij.0 for ; Sun, 12 Sep 2021 15:45:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vYAzsOvSkDtY09GauuZ4zmpfCyzpMIiyAretCmwv66M=; b=V4iU+RNS36ncdF+ELeHuMREUHqPn2Fh2TL6EvNdfCjo0Lquw8HBnUtS2Mu/jcbUoWB HLuyBqftHZQgWrOzarrWBeW23q6ZBElhT4AIw9Kq2Ur1JxGI1KEsSqM44o9d0uNDvoaH HlyJCIAkFAHL/10jQZbXrYEwres+6YXODJEY30A5VecDOn728hV5sij0QzU4wHEzFKm8 n6YPTGZIW/iZwJliMLLV3TXFTQcc1PCHZ6ttTiEHzRtcynmCjAcQc/cCrA+cKb7RZeCS +b96DXngJNULTqMPn67A+kZhThsb1GovhN9oQi0uR2N05po+dfKlY2A9YjxZTrOOoiJt FgGw== 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=vYAzsOvSkDtY09GauuZ4zmpfCyzpMIiyAretCmwv66M=; b=qGYmM59tpkLaUlmAqTLmE7YkhlHoVCs7Z/L6+KdsRMUPHLsyKdkMGu6IzcjM3poKV4 bit8wJuTcAjQU+5yWxQl8/O9Zl3Ru9kNjr3h5jpOvSXJCR8l69N72vf86z9bAeXu7iFB Mi737DJ/bxXkvNpP5a/tWUC/p2gSNNDCfJ6ap0l0bnKdZOdrCkAGcrbb1oVqbbGaWpVS a9YXoBDFcMJ4iR+K5WN9Aj6z5uo6S/FHd3hIVm5DIAmo0aKYTduUeuSS0agFiXXwQ7KL EFHAAP5BufhxDhhg7wzbeTlCb5b/+u9hJNGxHcGCRmdZJt8tjqhVMQijnaVR5qyXbNH3 t/4A== X-Gm-Message-State: AOAM531kfyQKaM5u+ikNajxD+il5m+Wf0YRPtdyqcDYelfySCZWkzvno 7bHfeiSam3tkwb80OLdJr3VHmcVfGDCj5+FS2r19F1OH9ysVbg== X-Google-Smtp-Source: ABdhPJxHPKnpzvH8CQUDebrwV6Dhz0327ec3KbhDWM2CF+blEOccB2HYKRyUrdsEfh6cuYa0znoA5uAQ1b/IBQaKd+Q= X-Received: by 2002:a05:6808:487:: with SMTP id z7mr5636467oid.11.1631486720234; Sun, 12 Sep 2021 15:45:20 -0700 (PDT) MIME-Version: 1.0 References: <8169A4A8-B8D1-4265-87C8-74ED4D34FBC8@fasel.at> <2bb56783-2727-9bea-7810-58969d91c00f@denninger.net> <0c3a5f3c-fb07-fae3-22f3-28703c842deb@obluda.cz> In-Reply-To: <0c3a5f3c-fb07-fae3-22f3-28703c842deb@obluda.cz> From: Tomasz CEDRO Date: Mon, 13 Sep 2021 00:44:38 +0200 Message-ID: Subject: Re: Important note for future FreeBSD base system OpenSSH update To: Ed Maste Cc: freebsd-security , Gordon Tetlow , Karl Denninger , Dan Lukes Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4H74Sc72GXz3Jcg X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cedro.info header.s=google header.b=V4iU+RNS; dmarc=none; spf=none (mx1.freebsd.org: domain of tomek@cedro.info has no SPF policy when checking 2607:f8b0:4864:20::235) smtp.mailfrom=tomek@cedro.info X-Spamd-Result: default: False [-2.56 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[cedro.info:s=google]; NEURAL_HAM_MEDIUM(-0.30)[-0.299]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org]; DMARC_NA(0.00)[cedro.info]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[cedro.info:+]; NEURAL_HAM_SHORT(-0.97)[-0.965]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::235:from]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-security] 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 22:45:22 -0000 On Mon, Sep 13, 2021 at 12:11 AM Dan Lukes wrote: > On 12.9.2021 23:27, Gordon Tetlow via freebsd-security wrote: > > Blaming the browser and other client providers (OpenSSH, etc) for a > > problem that is 100% because the devices are now abandoned by the > > manufacturer is the wrong place to focus your anger. We have an > > enormous problem in the industry of crappy embedded devices (like the > > OOB management plane) accruing technical security debt while the > > manufacturers give "a middle finger back" as you say. The > > supportability of the hardware needs to be baked into the purchasing > > decision. Commitments from the manufacturers on supportability > > timeframes are important to understand and budget into a hardware > > refresh cycle. > > "One size fits all" may be acceptable approach for unskilled home users, > but not for professional use. The security mechanism may be secure > enough for particular use even if there are known issues with the method > in question. > > There may be a various reason to abandon particular method/algorithm but > don't claim it's for my security because it's just not true. If > particular algorithm is not secure enough for me I'm not using it > despite it's supported. If algorithm is the best for particular case > (it's why I'm using it) the removal will decrease overall security of > such system. In no case the security will be increased. > > We should avoid to make decisions on behalf of skilled security officer > familiar with particular use case. Hey Ed, It seem that some people are tied to old infrastructure. Fallback to Port (or custom Kernel / Base?) seems reasonable. Will there be any alternative solution after upgrade or people will be forced to leave FreeBSD? Things start to look dramatic :-) What is the best and worst case scenario of the change? Is it only Base or also Kernel change? Would it be possible to use custom build of OpenSSH server (i.e. from Ports) with old algorithm enabled so it could work in place of the one being upgraded in base? I can see this approach seems to work for various services and utilities. Port seems easiest way to provide alternative solution? That way we would have secure solution by default and less secure custom solution but still easy to maintain when there is no other choice? -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-security@freebsd.org Mon Sep 13 00:07:38 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 2BAC7671255 for ; Mon, 13 Sep 2021 00:07:38 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H76HX2qszz3v8m for ; Mon, 13 Sep 2021 00:07:36 +0000 (UTC) (envelope-from dch@skunkwerks.at) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id AEDFC3200786; Sun, 12 Sep 2021 20:07:28 -0400 (EDT) Received: from imap44 ([10.202.2.94]) by compute4.internal (MEProxy); Sun, 12 Sep 2021 20:07:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skunkwerks.at; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm3; bh=dDuh7a7xi/gOgPrjRzLGUrGknXAF yH5kYcdh8b4Y7f8=; b=GZVgbqwsuDVPXidtnz87iCyYF/lDs2X6vMklbZJmbweI Id6lDfJQFgncDsS4Tql163ko0uVJQNFrU8lDzanU6zqt07W/WJSOsQVvdJUBRl5A JrshTk48Y3JMzC/OywfTlh0N+D1TCNp/WAlfjWaHhWLqzqwBNp4NNvxHQYqUmmKe scjU7/m0rph61OELOUPVCPcB81fJMAAjnL1+mwlgyWV26r3wEkos67A0azks7n3H soAW8R0fXP2xXG7vb42h5BdekG5M6ywIEV0sbONbwIo3vkafmB+O0OeqQh9M2j6p CNp9HtWVUaUJ3H+TURTHSYR66FLvgF9qpHoF+OWLEg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=dDuh7a 7xi/gOgPrjRzLGUrGknXAFyH5kYcdh8b4Y7f8=; b=tNSZwQXUBhfhvraxB5OqWs m6zxT0N9FFw2u5SoXuN2D1aw5KSN8wr+TSN62T0ZLfc3oCpNIEzb7OZAqTHtBqLM 6w+yMLmSDuIKZ8kvrAdJSwhHnR8o3mCZD7vcUl4EW2/8qUV8loemHHSY7eZXOAke +KhFtmxa67pHJYsP7aBCcVyIbebLSC28U15C+iSh+w+EVqnZanuL9sSP/QzEGxh6 o5XRaGBUfqk9ufRzEpyUBEfV76i5YLYbeQNgx3r/aNjs6C2p1L9NfW0E5zlRQkCE uexZmPZnxHrt07yU4ABmAjk09LEcO210mZU7jGnOwmcAXYnpWdrx3VGNmWyT9YYQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudegiedgfeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdffrghv vgcuvehothhtlhgvhhhusggvrhdfuceouggthhesshhkuhhnkhifvghrkhhsrdgrtheqne cuggftrfgrthhtvghrnhepkefffedvfeetkeffgefgffdvfeeugfeuhffhhfdufedvtefg ieelueejffehvdejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepuggthhesshhkuhhnkhifvghrkhhsrdgrth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 09119FA0AA5; Sun, 12 Sep 2021 20:07:26 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1229-g7ca81dfce5-fm-20210908.005-g7ca81dfc Mime-Version: 1.0 Message-Id: In-Reply-To: References: <8169A4A8-B8D1-4265-87C8-74ED4D34FBC8@fasel.at> <2bb56783-2727-9bea-7810-58969d91c00f@denninger.net> <0c3a5f3c-fb07-fae3-22f3-28703c842deb@obluda.cz> Date: Mon, 13 Sep 2021 00:07:06 +0000 From: "Dave Cottlehuber" To: "Tomasz CEDRO" , "Dan Lukes" Cc: freebsd-security , "Gordon Tetlow" , "Karl Denninger" Subject: Re: Important note for future FreeBSD base system OpenSSH update Content-Type: text/plain X-Rspamd-Queue-Id: 4H76HX2qszz3v8m X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=skunkwerks.at header.s=fm3 header.b=GZVgbqws; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=tNSZwQXU; dmarc=none; spf=pass (mx1.freebsd.org: domain of dch@skunkwerks.at designates 64.147.123.19 as permitted sender) smtp.mailfrom=dch@skunkwerks.at X-Spamd-Result: default: False [-3.59 / 15.00]; XM_UA_NO_VERSION(0.01)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:64.147.123.19]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[skunkwerks.at:+,messagingengine.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_LOW(-0.10)[64.147.123.19:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11403, ipnet:64.147.123.0/24, country:US]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[skunkwerks.at:s=fm3,messagingengine.com:s=fm3]; FREEFALL_USER(0.00)[dch]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[skunkwerks.at]; DWL_DNSWL_LOW(-1.00)[messagingengine.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[64.147.123.19:from]; MAILMAN_DEST(0.00)[freebsd-security]; MID_RHS_WWW(0.50)[] 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: Mon, 13 Sep 2021 00:07:38 -0000 > > > Blaming the browser and other client providers (OpenSSH, etc) for a > > > problem that is 100% because the devices are now abandoned by the > > > manufacturer is the wrong place to focus your anger. We have an > > > enormous problem in the industry of crappy embedded devices (like the Obviously just my humble opinion, but FreeBSD should, for new releases, turn the security *UP* to 11. No harm with knobs in installers, release notes, pointing out how to turn it down to 0 again. But it's 2020 now, and with hindsight, we see the long term cumulative effects of small poor security choices across the industry. If you refuse, or can't, upgrade the other infrastructure, and I totally respect that for a host of reasons, then don't upgrade this one either. Or stick a pi zero jump host in the middle (5$ maybe) to cater for this case if you want new shiny secure here, and old compat there. Where possible, we should enable easy backward compatibility. But, if like OpenSSH (or OpenSSL) if you need stuff that simply isn't acceptable anymore in a modern secure by default OS, then please don't drag the rest of FreeBSD back. By all means step up and help maintain ports that facilitate this use case! As dropbear only addded ed25519 keys in 2020, this is probbably a very suitable candidate for that. The argument that we will lose users "because backward compatibility" is equally as valid as "because insecure defaults that fail audits". Which is to say, not at all valid. The very definition of a straw man argument. Let's not sweep under the rug the very real effort and security risk that we introduce in favour of eternal backwards compatibility. If you *need* SSH 1.0, or TLS 1.1, or whatever the non-secure thing is, just DON'T UPGRADE. Just stay on 11.x or 12.x (supported to 2024), or worst case, install a jail or VM just for this. Or, do the work, help maintain an ever increasing swathe of patches to re-add what has been removed. But we all know that this path is both painful, and introduces security risks. I'd like less CVEs in my life. just my 0.05c for the other positions in this thread. A+ Dave From owner-freebsd-security@freebsd.org Tue Sep 14 01:07:48 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 231C46AE2DA for ; Tue, 14 Sep 2021 01:07:48 +0000 (UTC) (envelope-from dewayne@heuristicsystems.com.au) Received: from heuristicsystems.com.au (hermes.heuristicsystems.com.au [203.41.22.115]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2560 bits) client-digest SHA256) (Client CN "hermes.heuristicsystems.com.au", Issuer "Heuristic Systems Type 4 Host CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4H7lZV0tCCz3nJ8 for ; Tue, 14 Sep 2021 01:07:45 +0000 (UTC) (envelope-from dewayne@heuristicsystems.com.au) Received: from [10.0.5.3] (noddy.hs [10.0.5.3]) (authenticated bits=0) by heuristicsystems.com.au (8.15.2/8.15.2) with ESMTPSA id 18E1691F082287 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT) for ; Tue, 14 Sep 2021 11:06:10 +1000 (AEST) (envelope-from dewayne@heuristicsystems.com.au) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=heuristicsystems.com.au; s=hsa; t=1631581570; x=1632186371; bh=LNFKERTFKdMCggqtzko0k8CUgRMkuJabcZRhk7+A7UU=; h=Subject:To:From:Message-ID:Date; b=Xd62BiwJdHeK7QhyRDIaU+gZ7f9GH6ilFHz5kEMQwmcAB+lgHLstWTdwqnBkfJ0DG x+rWN8t5Cnpy9PFf82dl+dzPh2YrBz47lyZbs9LOWSfblqb2QzUQN3C5xycrxjLSOI PgMpPhBKSqcZmRTSykk6e5CPffTxPostuC450nZrlBMucL+Y0j5mE X-Authentication-Warning: b3.hs: Host noddy.hs [10.0.5.3] claimed to be [10.0.5.3] Subject: Re: Important note for future FreeBSD base system OpenSSH update To: freebsd-security@freebsd.org References: <8169A4A8-B8D1-4265-87C8-74ED4D34FBC8@fasel.at> From: Dewayne Geraghty Message-ID: <85d1dffc-729e-bb8c-32f8-46b452705fcd@heuristicsystems.com.au> Date: Tue, 14 Sep 2021 11:06:10 +1000 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <8169A4A8-B8D1-4265-87C8-74ED4D34FBC8@fasel.at> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Rspamd-Queue-Id: 4H7lZV0tCCz3nJ8 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=heuristicsystems.com.au header.s=hsa header.b=Xd62BiwJ; dmarc=none; spf=pass (mx1.freebsd.org: domain of dewayne@heuristicsystems.com.au designates 203.41.22.115 as permitted sender) smtp.mailfrom=dewayne@heuristicsystems.com.au X-Spamd-Result: default: False [-4.25 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; HAS_XAW(0.00)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; TO_DN_NONE(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[203.41.22.115:from]; DKIM_TRACE(0.00)[heuristicsystems.com.au:+]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1221, ipnet:203.40.0.0/13, country:AU]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[heuristicsystems.com.au:s=hsa]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_MED(-2.00)[heuristicsystems.com.au:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-security@freebsd.org]; DMARC_NA(0.00)[heuristicsystems.com.au]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_SHORT(0.95)[0.955]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-security] 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: Tue, 14 Sep 2021 01:07:48 -0000 Thank-you Ed, for providing a window for discussion. As much as I strongly agree with Dave Cottlehuber , there is sadly a pragmatic dimension.  So, off by default goes some way to improve the world, but folk do appear to need to be able to connect to "antique" equipment that they have no mechanism to upgrade (perhaps call for an ISO27001 audit? ;) ).  We really don't want to loose FreeBSDers for this. Minor point -  your ssh command line was helpful as it confirmed connectivity to an older FreeBSD9.1 system (still in use from 2014) using ed25519, and finally, to clarify that putty 0.75 (from May 2021) uses rsa-sha256; current version is 0.76, per https://www.chiark.greenend.org.uk/~sgtatham/putty/changes.html