Legacy option for key length?
Dan Mahoney (Gushi)
I occasionally manage some APC PDU devices. I manage them via a VPN,
which enforces super-heavy crypto, and their access is restricted to only
jumphosts and the VPN. Basically, the only time you need to log into
these is when you go to reboot something that's down.
Their web UI with SSL doesn't work with modern browsers.
Their CPU is...tiny, and their SSHd implementation is...old (and, I
believe, proprietary).
I think it defaults to RSA768, and even then, takes a good 15 seconds to
let you log in.
When trying to SSH to them most recently from a recent copy of MacOS, I
got the "Invalid Key Length" error.
I googled around for the release note and the source code commit that had
produced this, and then tried looking for workarounds here:
https://www.openssh.com/legacy.html
After all, since the OpenSSH devs think carefully enough to have a page
that documents legacy options, for sure they thought of one for this case
too, right? It doesn't seem so.
My workaround was, insanely, to fire up a VM with an older version of an
OS with an older openSSH client.
So...
Why not make minimum key length a tunable, just as the other options are?
In this way, sites with a more strict policy could actually specify it
(i.e. RSA2048 or better)
Perhaps if you're dead-set on this being so dangerous, you could make it
so that you could specify a command-line option to accept a lower value
one time, but you're perhaps not able to override it via the config.
Thanks,
-Dan
--
_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Stuart Henderson
> I occasionally manage some APC PDU devices. I manage them via a VPN,
> which enforces super-heavy crypto, and their access is restricted to only
> jumphosts and the VPN. Basically, the only time you need to log into
> these is when you go to reboot something that's down.
>
> Their web UI with SSL doesn't work with modern browsers.
> Their CPU is...tiny, and their SSHd implementation is...old (and, I
> believe, proprietary).
>
> I think it defaults to RSA768, and even then, takes a good 15 seconds to
> let you log in.
turned off SSH and switched to using telnet from the jumphost instead. Given how
crappy SSH is on these even when short keys were allowed, this was overall a big
improvement.
> I googled around for the release note and the source code commit that had
> produced this, and then tried looking for workarounds here:
> https://www.openssh.com/legacy.html
Daniel Kahn Gillmor
> Why not make minimum key length a tunable, just as the other options are?
answer the question "are you using it securely?"
you note that modern browsers (which do try to take security seriously,
despite their vast attack surface) have the same "problem" as the modern
OpenSSH ssh client does.
If you're responsible for those ADC devices, you should probably take
one of these avenues:
a) ask the vendor to release an upgrade to their firmware so that
you're not tied to their ancient (likely buggy) version.
b) ask the vendor to open their specs and upgrade channels so that
someone else could update their firmware
c) configure the devices to offer a non-secure protocol (e.g. telnet),
that never claims to be secure, if you're confident in the rest of
your network perimeter security
d) remove the devices and replace them with something that is actually
well-supported.
> Perhaps if you're dead-set on this being so dangerous,
insecure, it's the cryptanalysts who have shown that to be the case :)
> you could make it so that you could specify a command-line option to
> accept a lower value one time, but you're perhaps not able to override
> it via the config.
code to do terrible things, and you can recompile free software with
patches to make it do terrible things.
But please don't ask to make it easier for free software to do terrible
things to *other* people. That way lies things like the TLS "Export"
cipher suites, which are mistakes we are *still* paying for, decades
after their introduction.
If OpenSSH introduces this option, i'm sure we'll soon see it on stack
exchange as "how do i get ssh to work in condition $X?", at which point
the option or command-line argument will be copy/pasted into far more
places than it should be.
Please, don't make it easy to weaken this already-too-weak baseline.
All the best,
--dkg
David Newall
> On Thu 2017-12-28 21:31:28 -0800, Dan Mahoney (Gushi) wrote:
>> Why not make minimum key length a tunable, just as the other options
>> are?
> Because the goal of building secure software is to make it easy to
> answer the question "are you using it securely?"
>
important, allowed for an option which could only be used by explicitly
setting it at SSH invocation, so, that means, if you don't use the
option then you are (maybe) using it securely, and if you do use the
option, then you are using it in the most secure way possible (because
you'd only use it when forced to.)
By making it impossible for people to use SSH you are forcing people to
use less secure software; telnet because they can't use ssh; old, buggy
versions of ssh because that's what they had to install so that they
could connect to their industrial equipment.
The answer is also boneheaded:
> remove the devices and replace them with something that is actually
> well-supported
We'd be better removing arrogance from essential development teams,
people who think that replacing a world full of expensive and
functioning equipment is an option. It's not, and nor should it be.
That's a disgraceful suggestion and you should be ashamed of yourself.
Browser developers got it badly wrong; let's not join them. The
suggestion was good because there's a wide-spread need for shorter keys
and the suggested solution doesn't allow shorter keys unless explicitly
set per invocation.
Peter Moody
a *modern* openssh client to connect to an old, unpatched unmaintained
(by the vendor) sshd. i'd argue that's not the client's fault.
> you are forcing people to use
> less secure software; telnet because they can't use ssh;
has a history of not keeping their software patched. if everyone else
is similarly inclined, vendors will quickly take note.
> old, buggy versions
> of ssh because that's what they had to install so that they could connect to
> their industrial equipment.
maintaining old code isn't free. if you need the old options, ssh1
support, whatever, you should bear the cost of that yourself (by
keeping an old copy around, or compiling it yourself when you need
it). that cost shouldn't be borne by the openssh developers and not
the ret of the community.
David Newall
>> By making it impossible for people to use SSH
> nb, it's not impossible to use opessh. it might not be possible to use
> (by the vendor) sshd. i'd argue that's not the client's fault.
Of course it's the client's fault. The client worked, was changed, and
thus stopped working. The client wasn't faulty before, and the
difference was that some people thought it would be a good idea to break
compatibility with other standard-compliant software. That's got to be
the definition of "client's fault" (where "client" means "the people who
modified the client".)
>> you are forcing people to use
>> less secure software; telnet because they can't use ssh;
> alternative interpretation. i'm less likely to buy from a vendor who
> has a history of not keeping their software patched. if everyone else
> is similarly inclined, vendors will quickly take note.
You're blaming the victim? It's their fault for lacking prescience?
>> old, buggy versions
>> of ssh because that's what they had to install so that they could connect to
>> their industrial equipment.
> I'd personally be more worried about the buggy sshd to which I'm connecting.
By all means worry about that; but there's no suggestion that the
server, in this case, is buggy.
> maintaining old code isn't free. if you need the old options, ssh1
> support, whatever, you should bear the cost of that yourself (by
> keeping an old copy around, or compiling it yourself when you need
> it). that cost shouldn't be borne by the openssh developers and not
> the ret of the community.
The developers fucked up. They chose to expend effort breaking
backwards compatibility when they didn't have to. For the same effort
they could have deprecated shorter keys without disallowing them.
But, by all means, force people to use old versions. That's got to
advance security, doesn't it? Who knows, maybe you might even cause a
fork. Then there'd be openssh, which doesn't work with lots and lots of
stuff, and there'd be universalssh which works with everything, which
has all of the latest goodness of openssh (because, why wouldn't it?)
without any of the nastiness. Then Debian and Red Hat would switch, and
openssh would become an also-ran. Not a terrible result for the world
but a bad look for the core openssh developers.
David Newall
> The client wasn't faulty before, and the difference was that some people
> thought it would be a good idea to break compatibility
shorter keys: it needlessly breaks compatibility.
Peter Moody
> Of course it's the client's fault. The client worked, was changed, and thus
> stopped working.
pinning your dependencies when you have hard dependencies.
>> maintaining old code isn't free. if you need the old options, ssh1
>> support, whatever, you should bear the cost of that yourself (by
>> keeping an old copy around, or compiling it yourself when you need
>> it). that cost shouldn't be borne by the openssh developers and not
>> the ret of the community.
>
> The developers fucked up.
valuable point you might otherwise be making, you're doing it again.
Emmanuel Deloget
On Sat, Dec 30, 2017 at 12:16 AM, Daniel Kahn Gillmor <d...@fifthhorseman.net
> wrote:
> On Thu 2017-12-28 21:31:28 -0800, Dan Mahoney (Gushi) wrote:
>
>
> > Perhaps if you're dead-set on this being so dangerous,
>
> It's not the developers who are dead-set on weak-keyed RSA being
> insecure, it's the cryptanalysts who have shown that to be the case :)
>
To further supplement this point, here is the paper that explain how
RSA-768 was factorized. In 2010, the authors estimated that it would take
around 1500 years to a single-core machine of this generation to do the
same thing. We're 7 years after their first results, and we now have access
to massive cloud-based behemoths for a discount. How much time would it
resist?
The idea of removing weak ciphers from a widely used piece of software is a
good one - that way, you strengthen the whole ecosystem. Going the reverse
path would simply make less informed people be the weak link of the
Internet, putting possibly many more at risk.
Best regards,
-- Emmanuel Deloget
Emmanuel Deloget
> Hello,
>
> On Sat, Dec 30, 2017 at 12:16 AM, Daniel Kahn Gillmor <
> d...@fifthhorseman.net> wrote:
>
>> On Thu 2017-12-28 21:31:28 -0800, Dan Mahoney (Gushi) wrote:
>>
>>
>> > Perhaps if you're dead-set on this being so dangerous,
>>
>> It's not the developers who are dead-set on weak-keyed RSA being
>> insecure, it's the cryptanalysts who have shown that to be the case :)
>>
>
>
> To further supplement this point, here is the paper that explain how
> RSA-768 was factorized. In 2010, the authors estimated that it would take
> around 1500 years to a single-core machine of this generation to do the
> same thing. We're 7 years after their first results, and we now have access
> to massive cloud-based behemoths for a discount. How much time would it
> resist?
>
Of course, it's always better with the link itself:
https://eprint.iacr.org/2010/006.pdf
David Newall
> The idea of removing weak ciphers from a widely used piece of software is
> a good one - that way, you strengthen the whole ecosystem. Going the
> reverse path would simply make less informed people be the weak link of the
> Internet, putting possibly many more at risk.
This doesn't make the Internet more secure because people aren't about
to throw away expensive equipment just because the latest openssh throws
a hissy fit. They'll use an alternative. Perhaps the alternative will
be an older, less secure version of openssh. Perhaps it will be even
less secure telnet. They will continue to use their still-good
equipment, and so they should.
If people choose to use old versions of openssh, which is likely, they
may also choose to make that the only version they use. It makes a lot
of sense: it saves having to think about two different versions of the
same software, one which works properly and one which seems broken.
Force people to make this choice and you weaken the whole ecosystem.
Is there a way to stop people using weak ciphers without weakening the
ecosystem? There is a way which is close: make openssh not use weak
ciphers unless the user says "I really, really need to use this weak
cipher." That's all this is about. That doesn't weaken the ecosystem;
it makes it stronger.
Removing a weak cipher weakens the ecosystem by pushing people into
using old tools that have real bugs. It's also arrogant. it sounds too
much like, "you're too ignorant/lazy/cheap to decide what's right for
you so we'll make you do what we want, and we don't care how expensive
and disruptive it is for you."
Removing a weak cipher breaks things that it didn't need to break.
That's outrageous.
It does not hurt to make the weaker cipher an option. It's not hard, no
harder than the effort to remove it.
David Newall
> On Sat, Dec 30, 2017 at 9:47 PM, David Newall<ope...@davidnewall.com> wrote:
>> Of course it's the client's fault. The client worked, was changed, and thus
>> stopped working.
> don't upgrade your client. problem solved. you're at fault for not
> pinning your dependencies when you have hard dependencies.
Really? A fractured user-base: that's what you want? And you want to
blame the victims? People who don't discover that newer versions of
openssh don't work for equipment which they rarely need to access are at
fault for believing that what was promised would never be taken away?
Just leave them a little time bomb. Nice. Very nice.
Dan Mahoney (Gushi)
Not quite true.
I have some real options for people who come across this feed later. I
think the discussion is important, and I really wish that there was a
patchset available (similar to the HPN patches) that was well known and
maintained so that OS packagers had the option of using these options if
they never made it into core openssh.
In this particular case, it was not a removed cipher, per-se, it was
a weaker key-type. Changing the minimum key lengh is a define, in
sshkey.h I think. That was a one-line commit.
Adding support to make that an invoke-time tunable is more work, but I
think it's worth doing. If there's a developer who wants to do it in a
way that is reasonable, I'd ask what it would cost to sponsor that
feature.
Whatever the outcome, I'd suggest putting a note about this on the SSH
legacy options page, which is where I looked and where others might.
I.e. a list of things for which the openssh devs have decided NOT to be
backwards compatible with.
I might also suggest that since the support for ssh version 1 has been
removed from openssh, and since ssh v1 is an artifact, frozen in time,
which will never get any newer ciphers, that if I had to admin any systems
which only supported ssh v1, that I might compile a separate "ssh1" binary
which basically *forced* the -1 flag. (Think for those of us that use
tools like rancid to log into lots of equipment). To be clear, that's not
work I'd ask for from the ssh devs, but it would still make sense to
audit it as a separate project and borrow some clue.
===
For the record, for anyone else reading this thread who hit my exact
issue, there IS a way to get a 1024-bit cert onto the APC PDUs, but you
have to generate it from off-device using a windows-only utility, and then
scp it onto the device. It's a giant pain in the butt, but it does work.
If I had gotten a warning like "HEY THIS USES 768-BIT KEYS WHICH WILL BE
DEPRECATED IN A FUTURE VERSION OF SSH (within a year of $RELEASE DATE), I
may have done the annoying process sooner.
However, I found myself with an ssh instead that required installing a
whole other OS, because the removal of the feature left me with no way to
get into my kit and upgrade.
I could have also fallen back to serial as a long-term solution. Not
every device will have this option. Some of us have things like air
conditioning controllers, or temperature sensors, or UPSes or things with
tiny embedded controllers that really don't have this kind of a "patch
every tuesday" upgrade path.
Best wishes for 2018,
-Dan
--
Michael Ströder
> On 01/01/18 04:58, Emmanuel Deloget wrote:
>> The idea of removing weak ciphers from a widely used piece of software is
>> a good one - that way, you strengthen the whole ecosystem. Going the
>> reverse path would simply make less informed people be the weak link
>> of the
>> Internet, putting possibly many more at risk.
>
> This doesn't make the Internet more secure because people aren't about
> to throw away expensive equipment just because the latest openssh throws
> a hissy fit. They'll use an alternative. Perhaps the alternative will
> be an older, less secure version of openssh. Perhaps it will be even
> less secure telnet. They will continue to use their still-good
> equipment, and so they should.
strengths (already available for many years!) then it's very
questionable whether the equipment is "still-good".
Did you even try to ask the equipment's vendor for an update?
If yes, what was the outcome?
If there are no updates and being in your situation I would be really
concerned about other security issues buried in such unmaintained
systems. And most of my customers have a policy to sort out components
not maintained by the vendor anymore.
Ciao, Michael.
Peter Moody
* commercial vendors patched the software they sold
* people who purchased from these vendors to take responsibility for
their actions and apply pressure on the commercial vendors rather than
the free software developers who provide the client software, for
free.
and I'm not sure what your bugaboo is about a fractured user base; at
any given time there are probably hundreds of different versions of
openssh being distributed due to different os's, distros, etc.
by the way, do you not see that every one of your arguments about the
openssh client can be applied, almost verbatim, to the vendor supplied
sshd? with the obvious exception that one is supplied by a commercial
vendor.
bye
Gert Doering
On Mon, Jan 01, 2018 at 07:52:26AM -0800, Peter Moody wrote:
> I would prefer that:
>
> * commercial vendors patched the software they sold
> * people who purchased from these vendors to take responsibility for
> their actions and apply pressure on the commercial vendors rather than
> the free software developers who provide the client software, for
> free.
for UPSes and such, where the important part is "will that UPS provide
reliable power for a reasonable price", a secondary question is "can I
monitor that thing in a reasonable way?", and a very very very minor
influencing factor is "will the management card do SNMPv3, or SSH with o
2048 bit RSA key size"?
Your extreme point of view is just unrealistic for such devices and
vendors.
> and I'm not sure what your bugaboo is about a fractured user base; at
> any given time there are probably hundreds of different versions of
> openssh being distributed due to different os's, distros, etc.
>
> by the way, do you not see that every one of your arguments about the
> openssh client can be applied, almost verbatim, to the vendor supplied
> sshd? with the obvious exception that one is supplied by a commercial
> vendor.
I *have* seen this, and usually because the vendor imported a newer version
of OpenSSH, which broke existing functionality :-) (like, Fortigate, which
all of a sudden did not authenticate users with DSA keys anymore, and no
mentioning of it in the release notes...).
gert
--
now what should I write here...
Gert Doering - Munich, Germany ge...@greenie.muc.de
Michael Ströder
> On Mon, Jan 01, 2018 at 07:52:26AM -0800, Peter Moody wrote:
>> I would prefer that:
>>
>> * commercial vendors patched the software they sold
>> * people who purchased from these vendors to take responsibility for
>> their actions and apply pressure on the commercial vendors rather than
>> the free software developers who provide the client software, for
>> free.
>
> You *are* aware what people are talking about? Like, management cards
> for UPSes and such, where the important part is "will that UPS provide
> reliable power for a reasonable price", a secondary question is "can I
> monitor that thing in a reasonable way?", and a very very very minor
> influencing factor is "will the management card do SNMPv3, or SSH with o
> 2048 bit RSA key size"?
How high is the risk that this unmaintained device is added to
yet-another-bot-net in the Internet-of-shitty-devices or is used to
enter parts of your network.
If you run such devices you have to do your homework. Part of this is to
setup secured admin gateways where you can run whatever customized SSH
client you need to accomodate this moldy devices. It might turn out that
it's cheaper to buy new devices though.
Ciao, Michael.
Peter Moody
>
> I *have* seen this, and usually because the vendor imported a newer version
> of OpenSSH, which broke existing functionality :-) (like, Fortigate, which
> all of a sudden did not authenticate users with DSA keys anymore, and no
> mentioning of it in the release notes...).
but between the openssh devs and the fortigate qa team, whose fault is this? :)
Gert Doering
On Mon, Jan 01, 2018 at 09:19:22AM -0800, Peter Moody wrote:
> > Like, "making updates, and all of a sudden, working setups stop working"?
> >
> > I *have* seen this, and usually because the vendor imported a newer version
> > of OpenSSH, which broke existing functionality :-) (like, Fortigate, which
> > all of a sudden did not authenticate users with DSA keys anymore, and no
> > mentioning of it in the release notes...).
>
> I don't doubt it.
>
> but between the openssh devs and the fortigate qa team, whose fault is this? :)
QA team.
Supposedly vendors are supposed to import the latest and greatest software
all the time (your words, paraprased). So, they did everything right here,
except for the release notes...
"Taking away functionality that results in unexpected extra work for
the admin", well, whoever removed that functionality.
Damien Miller
> On Thu 2017-12-28 21:31:28 -0800, Dan Mahoney (Gushi) wrote:
> > Why not make minimum key length a tunable, just as the other options are?
>
> Because the goal of building secure software is to make it easy to
> answer the question "are you using it securely?"
never implemented the null cipher and also one of the reasons we removed
SSHv1.
We try to balance compatibility with avoiding danger. This is why it's
still possible to explicitly enable (weak, but AFAIK not broken) DSA
keys if you need them, but RSA768 has actually been demonstrated to be
broken with an academic team factoring a key back in 2009 at a work
factor that is easily reachable by a medium botnet or cloud service.
Adding a switch to turn these back on would be IMO irresponsible.
If you think this is overly parentalistic and that an experienced
admin is the one best equipped to assess risk, then I'd direct said
experienced admin to the the SSH_RSA_MINIMUM_MODULUS_SIZE definition in
sshkey.h that they can adjust themselves.
-d
David Newall
> If you think this is overly parentalistic and that an experienced
> admin is the one best equipped to assess risk, then I'd direct said
> experienced admin to the the SSH_RSA_MINIMUM_MODULUS_SIZE definition in
> sshkey.h that they can adjust themselves.
It is overly paternalistic, to use your word, because it's saying that
the user can't be trusted to not use a weak cipher in only those cases
where that's the only cipher available. It's saying that the only
acceptable access to said industrial equipment is no access.
David Newall
> I would prefer that:
>
> * commercial vendors patched the software they sold
We all would prefer that, but I think you know that in reality, very few
customers have enough leverage to achieve that. I have a number of IBM
servers for which access to the remote console now requires old versions
of Java and old browsers. That's IBM. If they're not going to update
equipment, nobody is. Let's not pretend the world works differently.
> I'm not sure what your bugaboo is about a fractured user base; at
> any given time there are probably hundreds of different versions of
> openssh being distributed due to different os's, distros, etc.
Every older version of openssh is on the path to the latest version,
unless there's a reason why the latest version cannot be used. When you
create such a reason, you force them to choose between a real bug or
find an alternative. A lot of people choose to live with a real bug,
and that truly does reduce security.
But the worst thing about fracturing the user base, from the perspective
of wanting to be the premiere implementation of ssh, is you create a
real incentive for a fork. As things stand, a fork would be superior
software, because it will have 100% of the goodness of openssh without
the badness. The main distributions will eventually switch and then
openssh will become irrelevant. Why go through that over some pig-headed
and wrong principle? (I realise that there are developers here who
think that it's not pig-headed to aim for perfect security, but, when
you make perfect be the enemy of good, you are being pig-headed.) What
is proposed has a strong argument in its favour, and really has no
downside, unless you believe in fairy godmothers who can wave a wand and
make manufacturers do things which they clearly are not going to.
> by the way, do you not see that every one of your arguments about the
> openssh client can be applied, almost verbatim, to the vendor supplied
> sshd?
I realise. I also realise that the reason why open source software is
so powerful a force in IT is because manufacturers want to their gear to
become obsolete, they want it to exist in their own silos, they want to
destroy the opposition. If I said "embrace, extend, extinguish",
everybody here would nod their head. Our job is to provide a better
alternative. This recent change, which removed shorter keys, could have
been done slightly differently and we would continue to be a better
alternative. Now, sadly, people have to dig into yesteryear and find a
better alternative. That not only sucks, it creates space for a good
alternative that will displace openssh.
I think a very good question which needs to be asked is, what value does
disallowing shorter keys bring over severely deprecating them (i.e.
allowing them by use of command argument on a per-session basis)? I
cannot see a single benefit; it won't stop use of shorter keys, it will
just stop use of the latest openssh.
David Newall
> How high is the risk that this unmaintained device is added to
> yet-another-bot-net in the Internet-of-shitty-devices or is used to
> enter parts of your network.
I think that is what is called a straw-man argument. If a device can be
compromised in the way you suggest, then I am sure it will be replaced,
but it will be replaced because it needs to be, not because its
management interface cannot be accessed via the latest openssh.
Disallowing use of openssh doesn't encourage people to throw away
expensive gear, it encourages them to throw away new versions of openssh.
Peter Moody
> disallowing shorter keys bring over severely deprecating them
have been told exactly how to enable them, here
https://lists.mindrot.org/pipermail/openssh-unix-dev/2018-January/036535.html
you seem to want someone else to do all the work for you.
good luck with that.
David Newall
On 02/01/18 16:05, Peter Moody wrote:
>> I think a very good question which needs to be asked is, what value does
>> disallowing shorter keys bring over severely deprecating them
> like you said, they have only been severely deprecated. further, you
> have been told exactly how to enable them, here
> https://lists.mindrot.org/pipermail/openssh-unix-dev/2018-January/036535.html
No, these shorter keys have been disallowed. There is no way to enable
them, other than to modify the software.
> you seem to want someone else to do all the work for you.
That is not true, and it was rather mean of you to say it. I am willing
to all the work, but there's no point doing that if it's just going to
be rejected out-of-hand, which seems to be the case.
Your position (per reference above) is that allowing use of shorter keys
is irresponsible. It's not. It is irresponsible to break other
people's equipment (which is what you want to do.) It is irresponsible
(for openssh) to push people to other software.
Peter Moody
support has been dropped by the upstream maintainer.
maintain your own version if you want otherwise unsupported options to
be available.
> I am willing to [do] all the work,
great. see my point above.
Ben Lindstrom
> I think a very good question which needs to be asked is, what value
> does disallowing shorter keys bring over severely deprecating them
> (i.e. allowing them by use of command argument on a per-session
> basis)? I cannot see a single benefit; it won't stop use of shorter
> keys, it will just stop use of the latest openssh.
longer acceptable? I can point out 20+ year old devices still running
sshv1 only protocol. Do we need to keep this complexity until that
number is zero? Even though it has been broken and known insecure for
decades.
And how many annoying "Do you really want to do this?" type questions do
you prompt the user and assume it is "fine"?
This is an honest question as that seems to be the core of the issue.
What balance between known insecure, complexity (allowing low value keys
in the client, prompting the user to verify they want to do this, and
disabling it in the server), and removing proven insecure features?
Ben
David Newall
> And how many annoying "Do you really want to do this?" type questions
> do you prompt the user and assume it is "fine"?
I think zero. I think the warning goes in the man page:
--allow-insecure-short-key This option allows use of keys shorter
than 1024 bits, however, it is known that such keys can be broken quite
quickly. You never want to use this option, unless you are connecting
to a server which does not allow a longer key.
Haven Tristan Hash
> I think zero.
That seems like a pretty untenable position.
Note that a less extreme stance than this (0!) still led OpenSSL to support
VMS, Netware and 16-bit Windows into 2014 and beyond. Creating a larger,
more complex codebase which contributed to security problems. Security
being the entire point, this was deemed by others (OpenBSD from whence
comes this very OpenSSH) to be counter-productive. OpenBSD then forked and
removed said support. So their philosophy on removing insecure baggage is
pretty clear and consistent.
It seems like you grant the point that the 768 bit keys are insecure and
you don't mind, in which case you likely already have an easily accesible
command line option to access these devices called telnet.
Haven Tristan Hash
then I see in that a tacit agreement that indeed there comes a time when
the userbase is small enough that it warrants removal/disablement
(especially if there is a security concern, even more especially in
security related software). Then it's just a question of when, and as is
their custom and prerrogative, OpenSSH chose earlier than you would have
liked in this case. Making such judgement calls is partially what made them
the popular SSH client/server that they are.
David Newall
> If you mean put zero warnings and not 'wait until there are zero
> users' then I see in that a tacit agreement that indeed there comes a
> time when the userbase is small enough that it warrants
> removal/disablement
There's no such tacit agreement because people won't know that they need
it until they discover that some old equipment, which has just been
working perfectly for years, suddenly cannot be accessed. The point
which you overlook is to not break peoples' things.
Haven Tristan Hash
>
> There's no such tacit agreement
>
disabling anything? Even if there are security implications? That would be
impractical and dangerous for the other users.
For edge case users like yourself they still offer the older versions.
Michael Ströder
> On 02/01/18 03:29, Michael Ströder wrote:
>> How high is the risk that this unmaintained device is added to
>> yet-another-bot-net in the Internet-of-shitty-devices or is used to
>> enter parts of your network.
>
> I think that is what is called a straw-man argument. If a device can be
> compromised in the way you suggest, then I am sure it will be replaced,
> but it will be replaced because it needs to be,
replaced?
(I do not claim that there's one good way to find out.)
Ciao, Michael.
Michael Ströder
> On 02/01/18 02:22, Peter Moody wrote:
>> I would prefer that:
>>
>> * commercial vendors patched the software they sold
>
> We all would prefer that, but I think you know that in reality, very few
> customers have enough leverage to achieve that. I have a number of IBM
> servers for which access to the remote console now requires old versions
> of Java and old browsers. That's IBM. If they're not going to update
> equipment, nobody is. Let's not pretend the world works differently.
Do you keep unpatched old browsers on all end-user systems?
If yes, good luck...
Ciao, Michael.
David Newall
> So they should have to wait until there are zero users before removing
> or disabling anything? Even if there are security implications? That
> would be impractical and dangerous for the other users.
As suggested, all new SSH servers would refuse a key which is too
short. What danger do you see?
Ingo Schwarze
would you kindly let this question rest now? You received an
official answer, and it is perfectly in line with long-established
and well-known OpenSSH project goals.
Please consider that every message on this list reaches a large
number of people, many of them quite busy professionals, so a good
signal-to-noise ratio is desirable.
Thanks,
Ingo
Cedric Blancher
> On Fri, 29 Dec 2017, Daniel Kahn Gillmor wrote:
>
>> On Thu 2017-12-28 21:31:28 -0800, Dan Mahoney (Gushi) wrote:
>> > Why not make minimum key length a tunable, just as the other options are?
>>
>> Because the goal of building secure software is to make it easy to
>> answer the question "are you using it securely?"
>
> This is a nice summation of our approach. It's the same reason we've
> never implemented the null cipher and also one of the reasons we removed
> SSHv1.
further updates.
Thanks to your broken policy of breaking backwards compatibility the
deployment of ssh has gotten a lot more insecure, i.e. you got exactly
the opposite of what you wanted to archive.
Maybe its time to have another April RFC, with ssh now as target and
with your name on it. I'd propose to make it mandatory for all sshv2
implementations too, and implement a 1 bit key and 1 bit password to
make sshv2 exactly that what it has become: Broken
Ced
--
Cedric Blancher <cedric....@gmail.com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur
Marc Haber
> On 02/01/18 03:29, Michael Ströder wrote:
> > How high is the risk that this unmaintained device is added to
> > yet-another-bot-net in the Internet-of-shitty-devices or is used to
> > enter parts of your network.
>
> I think that is what is called a straw-man argument. If a device can be
> compromised in the way you suggest, then I am sure it will be replaced, but
> it will be replaced because it needs to be, not because its management
> interface cannot be accessed via the latest openssh. Disallowing use of
> openssh doesn't encourage people to throw away expensive gear, it encourages
> them to throw away new versions of openssh.
Imagine an organization which has only reluctantly allowed their network
/ Unix admins to run Linux on their workstations and has only done so
with the admins' promise to run only the latest software.
And now, a bunch of older enterprise devices in the data center cannot
be accessed from those workstations any more.
The admins are forced to say "yes" to the question "will accessing the
device from an enterprise-standard Windows client work".
Now imagine the chance of the admins still being allowed to keep their
Linux workstations.
Not all installations are clueful.
And this all goes without mentioning that people are re-enabling telnet
on their APC powerstrips right in this second because OpenSSH won't work
any more.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Cedric Blancher
There is a simple solution: Hardware certified per MIL standards (US
DOD MIL standards) support kerberized telnet, so ssh can be declared
as "not needed" / "obsolete" for that purpose.
Ced
--
Cedric Blancher <cedric....@gmail.com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur
_______________________________________________
Nico Kadel-Garcia
<cedric....@gmail.com> wrote:
> There is a simple solution: Hardware certified per MIL standards (US
> DOD MIL standards) support kerberized telnet, so ssh can be declared
> as "not needed" / "obsolete" for that purpose.
*anything* requires a Kerberos server, a really reliable server or set
of servers, to manage the credentials. Many "kerberized telnet" setups
don't actually use the Kerberized telnet protocols on port 6623, they
just use the telnetd on port 23 of the telnetd server to authenticate
the user against the Kerberos server. And many obsolete, setups don't
even bother with *that*. Been there, done that, should have gotten
the T-shirt.
I'm afraid that many admins, even in DoD environments, fail to bother
with setting up these kinds of basic protections. Explaining the
distinctions can be... adventuresome.
Cedric Blancher
> On Tue, Jan 2, 2018 at 11:13 AM, Cedric Blancher
> <cedric....@gmail.com> wrote:
>
>> There is a simple solution: Hardware certified per MIL standards (US
>> DOD MIL standards) support kerberized telnet, so ssh can be declared
>> as "not needed" / "obsolete" for that purpose.
>
> And "if wishes were fishes, we'd all swim in riches". Kerberized
> *anything* requires a Kerberos server, a really reliable server or set
> of servers, to manage the credentials. Many "kerberized telnet" setups
> don't actually use the Kerberized telnet protocols on port 6623, they
> just use the telnetd on port 23 of the telnetd server to authenticate
> the user against the Kerberos server. And many obsolete, setups don't
> even bother with *that*. Been there, done that, should have gotten
> the T-shirt.
>
> I'm afraid that many admins, even in DoD environments, fail to bother
> with setting up these kinds of basic protections. Explaining the
> distinctions can be... adventuresome.
encryption, and whats the alternative now that OpenSSH is broken in a
way which requires 2 client binaries, one to talk to old servers and
one to talk to new servers?
I wish project Athena, of which Kerberos is the authentication part,
would've become more widespread, that would've avoided the mess we
have with single-island solutions a la "SSH".
Ced
--
Cedric Blancher <cedric....@gmail.com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur
Damien Miller
> Maybe its time to have another April RFC, with ssh now as target and
> with your name on it. I'd propose to make it mandatory for all sshv2
> implementations too, and implement a 1 bit key and 1 bit password to
> make sshv2 exactly that what it has become: Broken
into personal attack, let me be explicit now:
Abusive language, behaviour or personal attacks are not welcome on
this list and I will gleefully ban anyone who makes them.
Myself and the other OpenSSH developers are volunteers and while none of
us do it for adulation, we certainly don't do it for abuse. We can disagree
about technical matters without making it about individuals and without
being abusive.
-d