experchange > vms

Hans Blom (12-06-18, 03:57 PM)
Hello,
I'm running OpenVMS 8.3 and TCPIP V5.7 ECO4.
Filezilla has apparently decided that the kexalgorithm diffie-hellman-group1-sha1 is vulnerable and won't connect to any of my servers.
I upgraded one machine to TCPIP V5.7 ECO 5 and replaced a whole heap of SSH executables on recommendation of HPE. After reboot I entered KexAlgorithms diffie-hellman-group14-sha1 into the files SSH2_CONFIG. and SSHD2_CONFIG.
Now Filezilla can connect but outgoing or incoming SSH-session to/from other OpenVMS clients fail. OK, so I added KexAlgorithms diffie-hellman-group1-sha1 to the files too. Now connection to/from other clients work but Filezilla has again stopped working.
Any ideas anyone? Is the order of the KexAlgorithms lines relevant? Problem unsolvable?
Regards
Hans Blom
Stephen Hoffman (12-06-18, 05:01 PM)
On 2018-12-06 13:57:37 +0000, Hans Blom said:

[..]
> other clients work but Filezilla has again stopped working.
> Any ideas anyone? Is the order of the KexAlgorithms lines relevant?
> Problem unsolvable?


FileZilla is not doing anything particularly unusual, here. Various
systems have been deprecating old and known-insecure key exchanges,
MACs and ciphers, and the HP/HPE/VSI sshd implementations have been
slow to respond.

OpenVMS customers have been slow to upgrade, with the terminal HPE
version V8.4 having been available for ~eight years (and new-patches
for ~two more years), and with the much more recent VSI releases also
available.

What's happening here? Unfortunately, OpenVMS itself and iLOs have
down-revision sshd implementations.

While VSI will almost certainly upgrade sshd as part of the VSI IP and
a beta of same is presently underway for Itanium and a beta is planned
for Alpha, and the iLO is reportedly insufficient and incapable of
being upgraded.

The following ssh command will downgrade your connection security to
allow access into most (all?) OpenVMS systems and into most (all?)
OpenVMS-associated iLO management processors:

ssh -o HostKeyAlgorithms=ssh-rsa,ssh-dss -o
KexAlgorithms=diffie-hellman-group1-sha1 -o Ciphers=aes128-cbc,3des-cbc
-o MACs=hmac-md5,hmac-sha1 User

How you convince FileZilla to downgrade to these key exchange
algorithms, ciphers and MACs, you'll have to rummage. Based on a very
quick look at the macOS client and a quick doc search, I'm not certain
that FileZilla does allow downgrading a connection.

On most platforms, the command-line ssh and sftp clients will support
this or analogous syntax.

We're on an upgrade treadmill around ssh, TLS security, and related
details, and older software releases just won't connect to secure
platforms.
Dave Froble (12-06-18, 05:19 PM)
On 12/6/2018 10:01 AM, Stephen Hoffman wrote:
[..]
> We're on an upgrade treadmill around ssh, TLS security, and related
> details, and older software releases just won't connect to secure
> platforms.


Ya know, the real problem here, is dumb ass developers who cannot figure
out that perhaps there will be a time when a user just cannot use
encryption, and provide for an unencrypted option. Oh, no, that's way
too reasonable. Can't have that.

Then again, it's their product, and it's worth just about what you are
paying for it. Ain't free software great? Ain't the developers of free
software the smartest people around?

When you don't have to please the users, you can be as dumb as you want
to be ....
Stephen Hoffman (12-06-18, 05:57 PM)
On 2018-12-06 15:19:26 +0000, Dave Froble said:

> Ya know, the real problem here, is dumb ass developers who cannot
> figure out that perhaps there will be a time when a user just cannot
> use encryption, and provide for an unencrypted option. Oh, no, that's
> way too reasonable. Can't have that.


FileZilla offers FTP.

I wouldn't expect a security-focused client or server operating system
to even offer FTP access, though. Certainly not integrated and not
easily accessible, if FTP is to be available all.

> Then again, it's their product, and it's worth just about what you are
> paying for it. Ain't free software great? Ain't the developers of
> free software the smartest people around?


The FileZilla folks are investing in current security.

OpenVMS hasn't been focusing on security.

VSI is working to change that focus, with VSI IP and with other changes
shipping and additional work pending and planned.

The folks at VSI have far more work awaiting too, and the upgrade
cycles and the time-to-exploit windows are only going to shorten.

OpenVMS is not good at notifications, with building cases for upgrades,
and certainly not with the rapid deployment and installation of patches
and upgrades.

We are no longer in that fondly-remembered run-it-forever world.

In this and in other similar cases, OpenVMS and OpenVMS sites are
getting dragged forward by other platforms. That's... inauspicious.

In general, customers should be on HPE V8.4 at the oldest and with
current patches, and preferably either already running or migrating to
VSI OpenVMS. Many are not.

> When you don't have to please the users, you can be as dumb as you want
> to be ....


There are many potential antecedents for that sentiment.
Dave Froble (12-06-18, 06:22 PM)
On 12/6/2018 10:57 AM, Stephen Hoffman wrote:
> On 2018-12-06 15:19:26 +0000, Dave Froble said:
>> Ya know, the real problem here, is dumb ass developers who cannot
>> figure out that perhaps there will be a time when a user just cannot
>> use encryption, and provide for an unencrypted option. Oh, no, that's
>> way too reasonable. Can't have that.

> FileZilla offers FTP.


Hmmm ...

When I used it, I wasn't aware of that. Guess I must like the taste of
my foot ...
pcoviello (12-06-18, 07:07 PM)
Part of the issue in going forward with upgrades to the latest and greatest
are the software companies, we had intentions of upgrading from 8.4 to the
latest VSI version... but Intersystems Cache does not support it! sigh!
now the question is do we just go up to 1H1 that's supported or stay where
we are... knowing that possibly 2 years down the road it probably will be
replaced.

On Thursday, December 6, 2018 at 10:57:36 AM UTC-5, Stephen Hoffman wrote:
[..]
Stephen Hoffman (12-06-18, 08:16 PM)
On 2018-12-06 17:07:42 +0000, pcoviello said:

> Part of the issue in going forward with upgrades to the latest and
> greatest are the software companies, we had intentions of upgrading
> from 8.4 to the latest VSI version... but Intersystems Cache does not
> support it! sigh! now the question is do we just go up to 1H1 that's
> supported or stay where we are... knowing that possibly 2 years down
> the road it probably will be replaced.


Your organization has undoubtedly already discussed the InterSystems
support plans for Caché with the InterSystems folks, and they've
probably suggested porting your environment to a supported platform
such as Linux.

VSI has undoubtedly also been in discussions with InterSystems, too.

Your organization is also undoubtedly well aware of the end of HPE
OpenVMS new-patch support in ~two years, and the contemporaneous end of
InterSystems Caché 2017.1 support.

And your organization has likely also considered whether staying with
OpenVMS and porting to your own or to some hypothetical third-party
port of GT.M or ilk might be appropriate and might be financially
feasible here.

Inferring from all that and from your comments, this probably also
means your organization is headed off of OpenVMS, and that FileZilla
connectivity, and OpenVMS upgrades aren't particularly relevant outside
of critical outages.

Situations and interests and resources, and personal and organizational
agility varies widely, too.

Ports happen, platforms and strategies change, ISVs concentrate on and
move to platforms that are or will be most profitable for them, etc.

Some folks adapt to these sorts of app and platform changes, some folks
choose to retire, some get spun off, and some move on.



etc.
Simon Clubley (12-06-18, 08:57 PM)
On 2018-12-06, Dave Froble <davef> wrote:
> Ya know, the real problem here, is dumb ass developers who cannot figure
> out that perhaps there will be a time when a user just cannot use
> encryption, and provide for an unencrypted option. Oh, no, that's way
> too reasonable. Can't have that.


Actually, in many cases, you most certainly _cannot_ have that as either
site security standards or local industry/government security standards
outright ban the transmission of data via unencrypted means and maybe
even via secure protocols which are now deemed to be too weak.

If a VMS system can't operate in that environment, it's likely to get
replaced with an operating system which _can_ operate in that environment.

Simon.
Dave Froble (12-06-18, 11:52 PM)
On 12/6/2018 1:57 PM, Simon Clubley wrote:
> On 2018-12-06, Dave Froble <davef> wrote:
> Actually, in many cases, you most certainly _cannot_ have that as either
> site security standards or local industry/government security standards
> outright ban the transmission of data via unencrypted means and maybe
> even via secure protocols which are now deemed to be too weak.
> If a VMS system can't operate in that environment, it's likely to get
> replaced with an operating system which _can_ operate in that environment.
> Simon.


Applications are what people use, not operating systems. If your
application requires a particular operating system, then you are going
to use that operating system. Everything else is secondary.
IanD (12-07-18, 05:00 AM)
Tell that to the insurance companies and underwriters when you get hacked and your customer data walks and appears on the internet and then customers like up to sue

Insurance companies look for get out of jail clauses for but having to pay and running an OS that fails to keep up with industry best practices as faras security compliance is concerned brings a huge smile to their face because it does their job for them

The world has moved forward in terms of security requirements because the hackers have. Sending unencrypted data anywhere, even internally has not been best practice now for a very long time. More than ample notice of the retirement of insecure methods have been in the pipeline for a long time as well.

How long should software developers wishing to protect their clients and their own reputations need to accommodate those who refuse to move forward when it comes to security? Where is the cut off point?
Colin Butcher (12-07-18, 01:05 PM)
Filezilla 3.16.1 is the final version that works with older VMS versions
(including HP's V8.4 / TCPIP V5.7-ECO05) in my lab.

You should be able to download it from one of the many file servers out
there.
DuncanMorris (12-07-18, 01:25 PM)
On Friday, December 7, 2018 at 11:05:11 AM UTC, Colin Butcher wrote:
> Filezilla 3.16.1 is the final version that works with older VMS versions
> (including HP's V8.4 / TCPIP V5.7-ECO05) in my lab.
> You should be able to download it from one of the many file servers out
> there.


Filezilla 3.36 works with HP's V8.4 / TCPIP V5.7-ECO05, provided you also have the TCPIP-SSH-'arch'_V57-ECO5G patches installed.
Simon Clubley (12-07-18, 03:40 PM)
On 2018-12-06, IanD <iloveopenvms> wrote:
> Tell that to the insurance companies and underwriters when you get hacked
> and your customer data walks and appears on the internet and then customers
> like up to sue


[snip]

Exactly.

David is way off the mark here. Applications are _not_ what people use,
data is what people use and applications (and operating systems) are just
the method to access that data.

That data is protected both by organisation level controls and industry
or government level controls. Those controls get revised at regular
intervals based on various events and recommendations and if the
application/operating system cannot access the data within the constraints
of the updated controls, then it gets replaced with an application or
operating system which can.

In today's world, that is the only viable approach to take.

For a simple example, look at the various issues people are experiencing
here using VMS systems as various encryption algorithms and protocols
get removed and replaced with stronger ones.

Simon.
Stephen Hoffman (12-07-18, 06:14 PM)
On 2018-12-07 11:05:14 +0000, Colin Butcher said:

> Filezilla 3.16.1 is the final version that works with older VMS
> versions (including HP's V8.4 / TCPIP V5.7-ECO05) in my lab.
> You should be able to download it from one of the many file servers out there.


If this down-revision FileZilla is the path that you (the OP) chooses,
or using the ssh and sftp connection downgrade I'd mentioned
earlier—and not an HPE SSH patch or newer VSI sshd, or some other
remediation to bring OpenVMS forward to more recent connection
security—then definitely flag this decision and the tradeoffs with the
security folks or with management. This so that you (OP) don't solely
end up owning any breaches that might arise.

Another option here which hasn't been mentioned is to VPN into a
firewall located in front of the OpenVMS server. Yes, a firewall on an
internal network; isolating the OpenVMS server from even local traffic.
This approach also reduces the exposure of the OpenVMS system itself,
too.

And I'll just leave this OpenSSH discussion here:
Dave Froble (12-07-18, 07:16 PM)
On 12/7/2018 8:40 AM, Simon Clubley wrote:
[..]
> here using VMS systems as various encryption algorithms and protocols
> get removed and replaced with stronger ones.
> Simon.


Simon sez to boss, "we got to shut down operations cauz we ain't secure
....."

Boss sez to Simon, "but then we'll loss business, maybe be out of
business ...."

Simon sez to boss, "sorry, that's the only viable approach to take ...."

Boss sez to Simon , "I hope you got your resume up to date, you're going
to need it. You're fired!"

Simon sez "but I'm right"

Simon sez "how am I going to pay the rent?"

Simon sez "how am I going to eat?"

Simon sez "doesn't anybody care?"

Similar Threads