Re: Is there an option switch to lower minimum DH strength in SSH client?

[Theo de Raadt]

>I was finally able to bring our OpenBSD based Network Management System up
>to the current OS release (it was a couple of years out of date) but this
>process broke access to a large number of older HP switches on our network.
>Thorough analysis of the problem and study of the source code lead me to
>believe that the culprit is commit to usr.bin/ssh/dh.h rev 1.14:
>
>increase the minimum modulus that we will send or accept in
>diffie-hellman-group-exchange to 2048 bits;
>
>Within the file it further explains that this is mitigation for DH
>precomputation attacks. I understand and appreciate strengthening server
>code. But this breaks the use of SSH client leaving little recourse other
>than perhaps telnet with NO encryption instead of somewhat weak encryption,
>as the "server" is outside of our control. (I already checked that we have
>the latest firmware, less than one year old.)

If your switch management is located on a locked-down intranet, aka
'darknet', you can handle this with configuration, or not update the
clients that connect to their legacy servers.

But I guess they are not on a darknet, because you worry about telnet.

>Is this an oversight or is there a particular logic to intentionally
>breaking compatibility with a not-insignificant base of installed equipment?

Absolutely the latter.  It is intentional.  Security and
interopability often collide, especially as new research papers get
written and computational abilities expand.  Circumstances arise where
both needs cannot be satisfied and past decisions must be evaluated and
upgraded.  Decisions like this are not taken lightheartedly.

BTW you can contact HP tech support and tell them that the latest
Cisco Nexus productline just performed a update to latest (well 6
months ago) OpenSSH.  Including ditching SSH1 support.  Cisco has
shorter lifecycles than HP, but did so even for many EOL products in
that line.  So HP could get around to this.

Re: Is there an option switch to lower minimum DH strength in SSH client?

[Ryan Freeman]

On Fri, Nov 03, 2017 at 12:06:22AM -0400, Jacob Leifman wrote:
> I was finally able to bring our OpenBSD based Network Management System up
> to the current OS release (it was a couple of years out of date) but this
> process broke access to a large number of older HP switches on our network.
> Thorough analysis of the problem and study of the source code lead me to
> believe that the culprit is commit to usr.bin/ssh/dh.h rev 1.14:
> 
> increase the minimum modulus that we will send or accept in
> diffie-hellman-group-exchange to 2048 bits;
> 
> Within the file it further explains that this is mitigation for DH
> precomputation attacks. I understand and appreciate strengthening server
> code. But this breaks the use of SSH client leaving little recourse other
> than perhaps telnet with NO encryption instead of somewhat weak encryption,
> as the "server" is outside of our control. (I already checked that we have
> the latest firmware, less than one year old.)
> 
> Curiously, diffie-hellman-group1-sha1, which is the only one supported by
> the switches, is an accepted KexAlgorithm value in OpenSSH 7.6 (OBSD 6.2);
> I was hoping that I could use it to explicitly request smaller DH but
> ultimately it still dies with "Invalid key length" error.
> 
> Is this an oversight or is there a particular logic to intentionally
> breaking compatibility with a not-insignificant base of installed equipment?

While I agree with all the other posters that ideally all equipment
should be kept up-to-date rather than leaning on aging security
technology, I do realize that in some areas you simply have to get things
done and move on.

As such, I recommend this quick fix:

# pkg_add putty

This will give you the 'plink' command which is a cli putty ssh, and
it allows this stuff by default without making you add host entries
to ~/.ssh/config.  I have noticed it still does warn you when the end
point is using older ciphers but at least doesn't bomb out.

I started using this for older Cisco gear at $WORKPLACE as I grew tired
of editing the ssh config for the OpenSSH version :-)

Hope this helps,

Cheers!
-ryan

> 
> Thank you,
> 
> Jacob Leifman
> Educational Technology
> 
> Weymouth Public Schools
> 
> -- 
> CONFIDENTIALITY NOTICE: This e-mail message and any attachment to it is 
> intended only for the individual or entity to which it is addressed and may 
> contain confidential and/or privileged information. Any unauthorized 
> review, use, disclosure or distribution is prohibited. If you are not the 
> intended recipient, or the employee or agent responsible for delivering it 
> to the intended recipient, please contact the sender by reply e-mail and 
> destroy all copies of the original message. If you are the intended 
> recipient but do not wish to receive communication through this medium, 
> please advise the sender immediately. Please note that any views or 
> opinions presented in this email are solely those of the author and do not 
> necessarily represent those of the Weymouth Public Schools. 
> www.weymouthschools.org/

Re: Is there an option switch to lower minimum DH strength in SSH client?

[Allan Streib]

Chris Turner  writes:

> Encryption options can be selected by the client so long as they are available

Which is the issue. The change to usr.bin/ssh/dh.h was:

-#define DH_GRP_MIN 1024
+#define DH_GRP_MIN 2048

So the new DH_GRP_MIN value of 2048 is compiled in.

They could try reverting that commit locally and rebuilding.

Allan

Re: Is there an option switch to lower minimum DH strength in SSH client?

[Kapetanakis Giannis]

On 03/11/17 15:27, Jacob Leifman wrote:

>> KexAlgorithms +diffie-hellman-group1-sha1
>> Ciphers +aes128-cbc
>>
>> Regards
>>
> 
> Hi,
> 
> Not quite, I have the converse problem -- using the modern ssh client and
> being unable to connect to an older embedded ssh server. But your solution
> indicates that in the ssh server implementation the explicit compatibility
> mode actually works. I find the incongruity between server and client
> approaches to backwards compatibility rather odd, since it is generally
> much easier to upgrade or replace a client application (end-user software)
> than the server application, especially embedded server as in my case.
> 
> -Jacob.

The reverse is done on your .ssh/config

host old-server
Hostname 10.0.0.1
KexAlgorithms diffie-hellman-group-exchange-sha1
Ciphers 
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc

choose what works for you

ssh -v is a friend here to see where it complains.

G

Re: Is there an option switch to lower minimum DH strength in SSH client?

[Chris Turner]

On 11/03/17 08:27, Jacob Leifman wrote:


Not quite, I have the converse problem -- using the modern ssh client and
being unable to connect to an older embedded ssh server. But your solution
indicates that in the ssh server implementation the explicit compatibility
mode actually works.


Encryption options can be selected by the client so long as they are available

e.g.:

ssh -X -oHostKeyAlgorithms=+ssh-dss -oPubKeyAcceptedKeyTypes=+dsa

or by adding a host-specific option in a ~/.ssh/config entry.

See ssh_config(5) and ssh -Q options.

Re: Is there an option switch to lower minimum DH strength in SSH client?

[Jacob Leifman]

On Fri, Nov 3, 2017 at 9:17 AM, Solène Rapenne  wrote:

> Je 2017-11-03 05:06, Jacob Leifman skribis:
>
> I was finally able to bring our OpenBSD based Network Management System up
>> to the current OS release (it was a couple of years out of date) but this
>> process broke access to a large number of older HP switches on our
>> network.
>> Thorough analysis of the problem and study of the source code lead me to
>> believe that the culprit is commit to usr.bin/ssh/dh.h rev 1.14:
>>
>> increase the minimum modulus that we will send or accept in
>> diffie-hellman-group-exchange to 2048 bits;
>>
>> Within the file it further explains that this is mitigation for DH
>> precomputation attacks. I understand and appreciate strengthening server
>> code. But this breaks the use of SSH client leaving little recourse other
>> than perhaps telnet with NO encryption instead of somewhat weak
>> encryption,
>> as the "server" is outside of our control. (I already checked that we have
>> the latest firmware, less than one year old.)
>>
>> Curiously, diffie-hellman-group1-sha1, which is the only one supported by
>> the switches, is an accepted KexAlgorithm value in OpenSSH 7.6 (OBSD 6.2);
>> I was hoping that I could use it to explicitly request smaller DH but
>> ultimately it still dies with "Invalid key length" error.
>>
>> Is this an oversight or is there a particular logic to intentionally
>> breaking compatibility with a not-insignificant base of installed
>> equipment?
>>
>> Thank you,
>>
>> Jacob Leifman
>> Educational Technology
>>
>> Weymouth Public Schools
>>
>
> Hello,
>
> I'm not sure if it's what you ask but I had a problem with old ssh clients
> not able to connect to a recent ssh server after a system upgrade. I had to
> add this to my sshd config (on the server) to allow them to connect :
>
>
> KexAlgorithms +diffie-hellman-group1-sha1
> Ciphers +aes128-cbc
>
> Regards
>

Hi,

Not quite, I have the converse problem -- using the modern ssh client and
being unable to connect to an older embedded ssh server. But your solution
indicates that in the ssh server implementation the explicit compatibility
mode actually works. I find the incongruity between server and client
approaches to backwards compatibility rather odd, since it is generally
much easier to upgrade or replace a client application (end-user software)
than the server application, especially embedded server as in my case.

-Jacob.

-- 
CONFIDENTIALITY NOTICE: This e-mail message and any attachment to it is 
intended only for the individual or entity to which it is addressed and may 
contain confidential and/or privileged information. Any unauthorized 
review, use, disclosure or distribution is prohibited. If you are not the 
intended recipient, or the employee or agent responsible for delivering it 
to the intended recipient, please contact the sender by reply e-mail and 
destroy all copies of the original message. If you are the intended 
recipient but do not wish to receive communication through this medium, 
please advise the sender immediately. Please note that any views or 
opinions presented in this email are solely those of the author and do not 
necessarily represent those of the Weymouth Public Schools. 
www.weymouthschools.org/

Re: Is there an option switch to lower minimum DH strength in SSH client?

[Jacob Leifman]

On Fri, Nov 3, 2017 at 8:37 AM, Janne Johansson  wrote:

> 2017-11-03 5:06 GMT+01:00 Jacob Leifman  >:
>
>> I was finally able to bring our OpenBSD based Network Management System up
>> to the current OS release (it was a couple of years out of date) but this
>> process broke access to a large number of older HP switches on our
>> network.
>>
>
>
>> But this breaks the use of SSH client leaving little recourse other
>> than perhaps telnet with NO encryption instead of somewhat weak
>> encryption,
>> as the "server" is outside of our control. (I already checked that we have
>> the latest firmware, less than one year old.)
>>
>> Is this an oversight or is there a particular logic to intentionally
>> breaking compatibility with a not-insignificant base of installed
>> equipment?
>>
>>
> If your vendor, even with a <1y firmware still only can handle old and
> deprecated
> keysizes, you should not ask for everyone elses sshs to become worse, but
> rather
>
push the vendor to get up to speed, and since that will not work, you will
> have to
> resort to building older ssh and use that instead of the safer one that
> comes with
> the modern OS you upgraded to.
>
> Same goes for browsers and https, the bad parts of SSL/TLS gets weeded out
> in browsers
> so that the majority of users are safe, not kept to cater to the lowest
> common denominator
> of the laziest vendor still alive.
>
> You should be asking HP how come they can't keep the free sshd code
> updated,
> if security is your prime concern, not ask openbsd to lower everyone elses
> security.
>

I am not asking to lower anyone else's security or for SSH to "become
worse", I appreciate the default behavior being what it is. I am asking
about a way to have an explicit compatibility mode -- even if we are
successful at lobbying a behemoth like HP for an update, it will take time,
probably a lot of time. Nor is a chronically underfunded public school
district in the position to outright replace >$500K worth of switches that
do their primary duties without fail. Not having some kind of compatibility
mode, leaves me with choice of bad and worse. Typical K-12 management
neither understands tech nor can afford to divert funds to "frivolous"
upgrades. Their inevitable response is either "don't upgrade" or "choose
another product", a product that will not have even the basic security
level OpenBSD had say three years ago.


>
> --
> May the most significant bit of your life be positive.
>

-- 
CONFIDENTIALITY NOTICE: This e-mail message and any attachment to it is 
intended only for the individual or entity to which it is addressed and may 
contain confidential and/or privileged information. Any unauthorized 
review, use, disclosure or distribution is prohibited. If you are not the 
intended recipient, or the employee or agent responsible for delivering it 
to the intended recipient, please contact the sender by reply e-mail and 
destroy all copies of the original message. If you are the intended 
recipient but do not wish to receive communication through this medium, 
please advise the sender immediately. Please note that any views or 
opinions presented in this email are solely those of the author and do not 
necessarily represent those of the Weymouth Public Schools. 
www.weymouthschools.org/

Re: Is there an option switch to lower minimum DH strength in SSH client?

[Janne Johansson]

2017-11-03 14:17 GMT+01:00 Jacob Leifman 
:

> On Fri, Nov 3, 2017 at 8:37 AM, Janne Johansson 
> wrote:
>
>> 2017-11-03 5:06 GMT+01:00 Jacob Leifman > .org>:
>>
>>>
>>> If your vendor, even with a <1y firmware still only can handle old and
>> deprecated
>> keysizes, you should not ask for everyone elses sshs to become worse, but
>> rather
>>
> push the vendor to get up to speed, and since that will not work, you will
>> have to
>> resort to building older ssh and use that instead of the safer one that
>> comes with
>> the modern OS you upgraded to.
>>
>> I am not asking to lower anyone else's security or for SSH to "become
> worse", I appreciate the default behavior being what it is. I am asking
> about a way to have an explicit compatibility mode -- even if we are
> successful at lobbying a behemoth like HP for an update, it will take time,
> probably a lot of time. Nor is a chronically underfunded public school
> district in the position to outright replace >$500K worth of switches that
> do their primary duties without fail. Not having some kind of compatibility
> mode, leaves me with choice of bad and worse. Typical K-12 management
> neither understands tech nor can afford to divert funds to "frivolous"
> upgrades. Their inevitable response is either "don't upgrade" or "choose
> another product", a product that will not have even the basic security
> level OpenBSD had say three years ago.
>

compat =>
https://www.openssh.com/openbsd.html
scroll to the bottom, get one of the old versions and compile that.

cost: $0

Probably same amount as HP paid to be able to have a deprecated sshd in
their product.

-- 
May the most significant bit of your life be positive.

Re: Is there an option switch to lower minimum DH strength in SSH client?

[Solène Rapenne]

Je 2017-11-03 05:06, Jacob Leifman skribis:
I was finally able to bring our OpenBSD based Network Management System 
up
to the current OS release (it was a couple of years out of date) but 
this
process broke access to a large number of older HP switches on our 
network.
Thorough analysis of the problem and study of the source code lead me 
to

believe that the culprit is commit to usr.bin/ssh/dh.h rev 1.14:

increase the minimum modulus that we will send or accept in
diffie-hellman-group-exchange to 2048 bits;

Within the file it further explains that this is mitigation for DH
precomputation attacks. I understand and appreciate strengthening 
server
code. But this breaks the use of SSH client leaving little recourse 
other
than perhaps telnet with NO encryption instead of somewhat weak 
encryption,
as the "server" is outside of our control. (I already checked that we 
have

the latest firmware, less than one year old.)

Curiously, diffie-hellman-group1-sha1, which is the only one supported 
by
the switches, is an accepted KexAlgorithm value in OpenSSH 7.6 (OBSD 
6.2);

I was hoping that I could use it to explicitly request smaller DH but
ultimately it still dies with "Invalid key length" error.

Is this an oversight or is there a particular logic to intentionally
breaking compatibility with a not-insignificant base of installed 
equipment?


Thank you,

Jacob Leifman
Educational Technology

Weymouth Public Schools


Hello,

I'm not sure if it's what you ask but I had a problem with old ssh 
clients
not able to connect to a recent ssh server after a system upgrade. I had 
to

add this to my sshd config (on the server) to allow them to connect :


KexAlgorithms +diffie-hellman-group1-sha1
Ciphers +aes128-cbc

Regards

Re: Is there an option switch to lower minimum DH strength in SSH client?

[Janne Johansson]

2017-11-03 13:53 GMT+01:00 Gregory Edigarov :

> You should be asking HP how come they can't keep the free sshd code
>> updated,
>> if security is your prime concern, not ask openbsd to lower everyone elses
>> security.
>>
>> I think for most vendors, it is a rather administrative, than technical
> question.
> Yes, their technical people can update code, yes they can do it quick, but
> their management is slow...
>
>
I think you can let them update for decades and they will not update the
sshd anyhow.
So in the end, the conclusion was true, "since ssh has moved on, if I want
to keep using
my old hw, I need to resort to insecure ways of administering them", where
it may be
ancient ssh clients or telnet or serial ports.

When it comes to IT security, stuff like "was removed 2 years ago, and
deprecated for
X years before that, and better versions have been available for X+Y years"
actually
matters.

You can wave your arms and pretend as if this was a big shock for you, but
actually there is a lot of diligence being skipped in order for someone to
end up in a
situation like this. And not just in the customer end, but the vendor also.
And everyone
else that keep an unpatched admin station around just to make that random
old system
going even though vendors claim to care for your security.

-- 
May the most significant bit of your life be positive.

Re: Is there an option switch to lower minimum DH strength in SSH client?

[Otto Moerbeek]

On Fri, Nov 03, 2017 at 02:53:53PM +0200, Gregory Edigarov wrote:

> I think for most vendors, it is a rather administrative, than technical
> question.
> Yes, their technical people can update code, yes they can do it quick, but
> their management is slow...

Often, the same management is telling everybody security is of the
highest concern to them, so make them deliver on that.

-Otto

Re: Is there an option switch to lower minimum DH strength in SSH client?

[Gregory Edigarov]

On 03.11.17 14:37, Janne Johansson wrote:

2017-11-03 5:06 GMT+01:00 Jacob Leifman :


I was finally able to bring our OpenBSD based Network Management System up
to the current OS release (it was a couple of years out of date) but this
process broke access to a large number of older HP switches on our network.




But this breaks the use of SSH client leaving little recourse other
than perhaps telnet with NO encryption instead of somewhat weak encryption,
as the "server" is outside of our control. (I already checked that we have
the latest firmware, less than one year old.)

Is this an oversight or is there a particular logic to intentionally
breaking compatibility with a not-insignificant base of installed
equipment?



If your vendor, even with a <1y firmware still only can handle old and
deprecated
keysizes, you should not ask for everyone elses sshs to become worse, but
rather
push the vendor to get up to speed, and since that will not work, you will
have to
resort to building older ssh and use that instead of the safer one that
comes with
the modern OS you upgraded to.

Same goes for browsers and https, the bad parts of SSL/TLS gets weeded out
in browsers
so that the majority of users are safe, not kept to cater to the lowest
common denominator
of the laziest vendor still alive.

You should be asking HP how come they can't keep the free sshd code updated,
if security is your prime concern, not ask openbsd to lower everyone elses
security.

I think for most vendors, it is a rather administrative, than technical 
question.
Yes, their technical people can update code, yes they can do it quick, 
but their management is slow...

Re: Is there an option switch to lower minimum DH strength in SSH client?

[Janne Johansson]

2017-11-03 5:06 GMT+01:00 Jacob Leifman :

> I was finally able to bring our OpenBSD based Network Management System up
> to the current OS release (it was a couple of years out of date) but this
> process broke access to a large number of older HP switches on our network.
>


> But this breaks the use of SSH client leaving little recourse other
> than perhaps telnet with NO encryption instead of somewhat weak encryption,
> as the "server" is outside of our control. (I already checked that we have
> the latest firmware, less than one year old.)
>
> Is this an oversight or is there a particular logic to intentionally
> breaking compatibility with a not-insignificant base of installed
> equipment?
>
>
If your vendor, even with a <1y firmware still only can handle old and
deprecated
keysizes, you should not ask for everyone elses sshs to become worse, but
rather
push the vendor to get up to speed, and since that will not work, you will
have to
resort to building older ssh and use that instead of the safer one that
comes with
the modern OS you upgraded to.

Same goes for browsers and https, the bad parts of SSL/TLS gets weeded out
in browsers
so that the majority of users are safe, not kept to cater to the lowest
common denominator
of the laziest vendor still alive.

You should be asking HP how come they can't keep the free sshd code updated,
if security is your prime concern, not ask openbsd to lower everyone elses
security.

-- 
May the most significant bit of your life be positive.