openssh unix dev - Dec 2019 - Settable minimum RSA key sizes on the client end for legacy devices.

On 12/26/19 6:35 AM, Stuart Henderson wrote:
> On 2019/12/25 21:02, Steve Sether wrote:
>> Basically I've had to turn on telnet access again, lowering
security.
> Does it really lower security? The very old embedded OS is not going to
> be secure anyway, this type of device should only be used on a trusted
> private network. (New embedded OS are often not much better so I'd take
> the same view there).
>
> The RNG used to generate the key is probably rubbish too - I don't
expect
> there to be all that much entropy in those 768 bits..
>
> Not being able to use ssh is an annoyance but there are trade-offs to be
> made when using old hardware. The way I deal with these is to use telnet
> from a console server / "jump box" which itself runs modern sshd.
For me personally?? No.? This is my home device, and I'm not really all 
that worried. For a lot of companies in the world? Absolutely.? This is 
primarily because it's extremely common to re-use administrator 
passwords.? Sniff some network traffic and raise your privilege level.? 
I think most people agree that the perimeter defense is not something 
you should rely on, and to use encryption inside your own network.? I 
understand that one can perform mitigations to lower the risk, but it 
just doesn't make sense to me that openSSH has decided to not support this.

I've no doubt that someone could (likely) hack into the APC-UPS device 
with enough effort.? I don't personally know of any vulnerabilities for 
this device, (and I did just check).? So hacking into it would take some 
effort, finding an exploit, writing some kind of means to obtain a 
password from the device, etc.? Sniffing telnet and doing ARP poisoning 
attacks and the like is pretty trivial by comparison.? These are well 
known ways to obtain passwords that have been around for 20+ years, and 
the very reason ssh was invented in the 90s.

Someone here suggested generating a 1024 bit RSA key offline and 
uploading it.? That's exactly what I tried doing, and the APC rejected 
it.? I suspect because, as you say below, the CPU isn't powerful enough 
for a 1024 bit key.
>> To me, not providing a way to over-ride the minimum key size is just a
bit
>> heavy-handed.? The vendor doesn't support this device anymore, and
it's
>> failed all attempts at replacing the 768 bit key with a 1024 bit one.
> The APC devices I used struggled with even a 768-bit key, I suspect
> handling numbers 2^256 times larger will be too hard on the CPU.
>
>> I note that other legacy, potentially insecure options are supported
via
>> configuration changes. https://www.openssh.com/legacy.html
> Most of these (though not ssh-dss) relate to per-session keying.
> I think you can get away with a bit more weakness there (which would
> have to be attacked while the session is active and before rekeying)
> whereas short host keys are more of a long term risk.
>
> Note that other things were removed with no fallback available (also
> with good reason) - SSH1 for example.
ssh1 I can certainly understand, primarily because maintaining the 
protocol requires maintenance.? I don't see a huge amount of maintenance 
in a config option for minimum key size.? I also don't know that I've 
seen a device that only supports SSH1.? IIRC ssh2 came out in something 
like 1996, shortly after ssh1.? I'm not even sure if ssh1 really gained 
much popularity, since those early days it was just Tatu with his idea 
of encrypted telnet.

I guess my main problem with setting this hard-coded is that it puts a 
LOT of control in the hands of the developers, and little or no control 
in the system administrators.? i.e. "We Know What's Good For
You!".?
Well, not for everyone.? One size rarely fits all.

>> Why isn't the
>> same true for a minimum key size?? This device isn't exactly
ancient at
>> around 12 years old and a 10 year old firmware.? I'd imagine
there's other
>> hardware that has limited support for ssh key sizes that the current
>> openssh won't connect to anymore.
> The other place I've seen it is on old switches but there is usually
> less reason to keep them than old power control hardware.
>
>> I'd rather not dredge up a big fight, but I _would_ like to express
a
>> desire for some form of overriding the minimum key size.
> This can be done by recompiling if necessary. This restriction has been
> a pain for me at times but honestly I think it's for the best that
it's
> been done.
>

I fully agree with Steve here, and dislike developers' attitude of "We
know what's good for you, and since you don't/can't have a clue - we
won't trust you with decisions".

Minimal key size should have a "reasonable" default, and an explicit
config parameter to override it and set to whatever value that *specific*
installation needs. There's no way  the developers can know or evaluate
every possible use case or related threat model - so they shouldn't behave
as if they do...

Regards,
Uri
> On Dec 26, 2019, at 15:30, Steve Sether <steve at sether.org> wrote:
> 
> ?
>> On 12/26/19 6:35 AM, Stuart Henderson wrote:
>>> On 2019/12/25 21:02, Steve Sether wrote:
>>> Basically I've had to turn on telnet access again, lowering
security.
>> Does it really lower security? The very old embedded OS is not going to
>> be secure anyway, this type of device should only be used on a trusted
>> private network. (New embedded OS are often not much better so I'd
take
>> the same view there).
>> 
>> The RNG used to generate the key is probably rubbish too - I don't
expect
>> there to be all that much entropy in those 768 bits..
>> 
>> Not being able to use ssh is an annoyance but there are trade-offs to
be
>> made when using old hardware. The way I deal with these is to use
telnet
>> from a console server / "jump box" which itself runs modern
sshd.
> 
> For me personally?  No.  This is my home device, and I'm not really all
that worried. For a lot of companies in the world? Absolutely.  This is
primarily because it's extremely common to re-use administrator passwords. 
Sniff some network traffic and raise your privilege level.  I think most people
agree that the perimeter defense is not something you should rely on, and to use
encryption inside your own network.  I understand that one can perform
mitigations to lower the risk, but it just doesn't make sense to me that
openSSH has decided to not support this.
> 
> I've no doubt that someone could (likely) hack into the APC-UPS device
with enough effort.  I don't personally know of any vulnerabilities for this
device, (and I did just check).  So hacking into it would take some effort,
finding an exploit, writing some kind of means to obtain a password from the
device, etc.  Sniffing telnet and doing ARP poisoning attacks and the like is
pretty trivial by comparison.  These are well known ways to obtain passwords
that have been around for 20+ years, and the very reason ssh was invented in the
90s.
> 
> Someone here suggested generating a 1024 bit RSA key offline and uploading
it.  That's exactly what I tried doing, and the APC rejected it.  I suspect
because, as you say below, the CPU isn't powerful enough for a 1024 bit key.
> 
>>> To me, not providing a way to over-ride the minimum key size is
just a bit
>>> heavy-handed.  The vendor doesn't support this device anymore,
and it's
>>> failed all attempts at replacing the 768 bit key with a 1024 bit
one.
>> The APC devices I used struggled with even a 768-bit key, I suspect
>> handling numbers 2^256 times larger will be too hard on the CPU.
>> 
>>> I note that other legacy, potentially insecure options are
supported via
>>> configuration changes. https://www.openssh.com/legacy.html
>> Most of these (though not ssh-dss) relate to per-session keying.
>> I think you can get away with a bit more weakness there (which would
>> have to be attacked while the session is active and before rekeying)
>> whereas short host keys are more of a long term risk.
>> 
>> Note that other things were removed with no fallback available (also
>> with good reason) - SSH1 for example.
> 
> ssh1 I can certainly understand, primarily because maintaining the protocol
requires maintenance.  I don't see a huge amount of maintenance in a config
option for minimum key size.  I also don't know that I've seen a device
that only supports SSH1.  IIRC ssh2 came out in something like 1996, shortly
after ssh1.  I'm not even sure if ssh1 really gained much popularity, since
those early days it was just Tatu with his idea of encrypted telnet.
> 
> I guess my main problem with setting this hard-coded is that it puts a LOT
of control in the hands of the developers, and little or no control in the
system administrators.  i.e. "We Know What's Good For You!". 
Well, not for everyone.  One size rarely fits all.
> 
> 
>>> Why isn't the
>>> same true for a minimum key size?  This device isn't exactly
ancient at
>>> around 12 years old and a 10 year old firmware.  I'd imagine
there's other
>>> hardware that has limited support for ssh key sizes that the
current
>>> openssh won't connect to anymore.
>> The other place I've seen it is on old switches but there is
usually
>> less reason to keep them than old power control hardware.
>> 
>>> I'd rather not dredge up a big fight, but I _would_ like to
express a
>>> desire for some form of overriding the minimum key size.
>> This can be done by recompiling if necessary. This restriction has been
>> a pain for me at times but honestly I think it's for the best that
it's
>> been done.
>> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5874 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20191226/01be9907/attachment-0001.p7s>

> I fully agree with Steve here, and dislike developers' attitude of
"We
> know what's good for you, and since you don't/can't have a clue
- we
> won't trust you with decisions".
Well, I'm on the developers' side.
They need to produce a product that _now_ gets installed in some
embedded device and is expected to be still secure in 15 years and
longer - as this thread proves.

So the emphasis _must_ be on conservative defaults.


But I've been on the other side as well 20 years ago, trying to run SSH
on a 200MHz RISC machine... Engineering sometimes needs trade-offs,
yeah.

> Minimal key size should have a "reasonable" default, and an
explicit
> config parameter to override it and set to whatever value that
> *specific* installation needs.
No, that's too easy.
I've seen too many decisions made on such a basis - "just configure
security down until it works" - but these invariably lead to disaster.


Still, recompilation has a too variable cost (in the dependencies) -
it's hard to be sure that you _only_ changed that one constant and
didn't forget something that ./configure would have found etc.

> There's no way  the developers can know
> or evaluate every possible use case or related threat model -
No, they don't.
They only know the most common 90%, of which eg. _I_ probably
only know 20%.

> so they
> shouldn't behave as if they do...
Well, like a parent they try to save you from bad decisions.