Date: Sun, 12 Sep 2021 10:40:49 -0400 From: Karl Denninger <karl@denninger.net> To: freebsd-security@freebsd.org Subject: Re: Important note for future FreeBSD base system OpenSSH update Message-ID: <2bb56783-2727-9bea-7810-58969d91c00f@denninger.net> In-Reply-To: <8169A4A8-B8D1-4265-87C8-74ED4D34FBC8@fasel.at> References: <CAPyFy2A390kS_C3g=Y9QhQcJ06z_FKUxXsNvi9g2CdWF24pukg@mail.gmail.com> <CAPyFy2B04b0GtWoHFQwxht5vK4_cnApPXpDLXU%2BRvcR=2L9YxA@mail.gmail.com> <CAPyFy2Aw8Z3ngiM8YHApjjPRLZVC5MCN8TRQkh6pj2fSeM1zqw@mail.gmail.com> <8169A4A8-B8D1-4265-87C8-74ED4D34FBC8@fasel.at>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
On 9/12/2021 10:02, Markus Falb wrote:
>> On 09.09.2021, at 20:01, Ed Maste <emaste@freebsd.org> 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 <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
[-- Attachment #2 --]
0 *H
010
`He 0 *H
00 H^Ōc!5
H0
*H
01 0 UUS10U Florida10U Niceville10U
Cuda Systems LLC10U Cuda Systems CA1!0 U Cuda Systems LLC 2017 CA0
170817164217Z
270815164217Z0{1 0 UUS10U Florida10U
Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA0"0
*H
0
h-5B>[;olӴ0~͎O9}9Ye*$ g !ukvʶLzN`jL>MD'7U 45CB+kY`bd~b*c3Ny-78ju]9H euέsӬDؽmgwER?&UURj'}9nWD i`XcbGz \gG=u%\Oi13ߝ4
K44pYQr]Ie/r0+eEޝݖ0C15Mݚ@JSZ(zȏ NTa(25DD5.l<g[[Z arQQ%Buȴ~~`IohRbʳڟu2MS8EdFUClCMaѳ !}ș+2k/bųE,n当ꖛ\(8 WV8 d]b yXw ܊:I39
00 U ]^§Q\ӎ0U #0T039N0b01 0 UUS10U Florida10U Niceville10U
Cuda Systems LLC10U Cuda Systems CA1!0 U Cuda Systems LLC 2017 CA @Ui0U 0 0U 0
*H
:P U!>vJ n io -#ן]Wyu jǑR̀Q
nƇ!G ѦF g\ yLx gw=OPycehf[ }ܷ['4ڝ\[p 6\o.B&JF" ZC{;*o*mcCcLY߾`
t*S!(` ]DHP5A~/NPp6=mhk밣'doA$86hm5ӚS@ j ެEgl
)0JG`%k35PaC?σ
׳HEt}!P㏏%*BxbQwaKG$6 h¦Mve; [o-Iی&
I,Tc ߎ#t wPA@l0P+KXBպT zGv;NcI3&J ĬUPNa?/%W6G۟N000 k#Xd\ =0
*H
0{1 0 UUS10U Florida10U
Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA0
170817212120Z
220816212120Z0W1 0 UUS10U Florida10U
Cuda Systems LLC10U karl@denninger.net0"0
*H
0
T[I-ΆϏ dn;Å@שy.us~_ZG%<MYd\gvfnsa1'6Egyjs"C [{~ _K Pn+<*pv#Q+H/7[-vqDV^U>f%GX)H.|l`M(Cr >е͇6#odc"YljҦln8@5SA0&ۖ"OGj?UDWZ5 dDB 7k-)9Izs-JAv
J 6L$Ն1SmY.Lqw*SH;EF'DĦH]MOgQQ|Mٙג2Z9y@ y]}6ٽeY9Y2xˆ$T=e CǺǵbn֛{j |@LLt1[Dk5:$= ` M 00<+00.0,+0 http://ocsp.cudasystems.net:88880 U 0 0 `HB0U 0 U %0++03 `HB
&$OpenSSL Generated Client Certificate0 U %՞V =;bzQ0U #0]^§Q\ӎϡ01 0 UUS10U Florida10U Niceville10U
Cuda Systems LLC10U Cuda Systems CA1!0 U Cuda Systems LLC 2017 CA H^Ōc!5
H0 U 0karl@denninger.net0
*H
۠A0-j%--$% g2#ޡ1^>{K+uGE v1ş7Af&b&O; .;A5* U)ND2bF|\= ]<sˋL!wrw٧> YMÄ3\mWR hSv!_zvl? 3_ xU%\^#O*Gk̍YI_&Fꊛ@&1n } ͬ:{hTP3B.;bU8:Z=^Gw8 !k-@xE@i,+'Iᐚ:f hztX7/(hY` O.1}a`%RW^akǂpCAufgDix UTЩ/7}%=jnVZvcF<M=
2^GKH5魉
_O4ެByʈySkw=5@h.0z>
W1000{1 0 UUS10U Florida10U
Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA k#Xd\ =0
`He E0 *H
1 *H
0 *H
1
210912144050Z0O *H
1B@Q@ \K8mu;s@64"pw$)s5;)s>0l *H
1_0]0 `He*0 `He0
*H
0*H
0
*H
@0+0
*H
(0 +7100{1 0 UUS10U Florida10U
Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA k#Xd\ =0 *H
10{1 0 UUS10U Florida10U
Cuda Systems LLC10U Cuda Systems CA1%0#U Cuda Systems LLC 2017 Int CA k#Xd\ =0
*H
BoJ^FNNO 8Zz$X&g FԢk5a/Qܼta=BKFG'(Mۢpj
Rmn:8c^9{pY-31 c
wBK;嬅H` $hf>@.8Ο8}a +"ZHrƉŁ7aI Ҝ!(8}' jj(֕i1&
r2.V8*Rx[QQ̡V gD1w,vƮ ?]ga EWj2iJb 5ʍ*gf-"3# }i7@^o9vKj:EKm_Hb)Q2]ѮSO-p+Z8+.sěn-m" -|Tr x+<okEZ$Dɋbh /qv\'64;{ig7q !6^o"]uhug~ #3/Ý`ϨЖо
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2bb56783-2727-9bea-7810-58969d91c00f>