SSL3 on OpenVMS V8.4-2L3

[jeffrey_dsi]

We recently updated a customer to OpenVMS V8.4-2l3 and SSL3 v3.0-13
after many conversations with VSI as to which version of SSL to run.

We have a cron job that produces an xml file and uses sftp to push it to
the VMS system. In the script it did a "cd pipeline_data" which was a
system logical for where the file needs to go. This doesn't work as SSL
doesn't appear to understand logicals. I had to change it to "cd
/lda105/pipeline_data" to get it to work.

This breaks my rule that no script/com file should have a real device
name except for sys$manager:logicals.com. I put a remark in the
logicals.com to remind me of the new dependency if that logical changes.

Jeff Coffield
www.digitalsynergyinc.com

[Simon Clubley]

Post by jeffrey_dsi
We recently updated a customer to OpenVMS V8.4-2l3 and SSL3 v3.0-13
after many conversations with VSI as to which version of SSL to run.
We have a cron job that produces an xml file and uses sftp to push it to
the VMS system. In the script it did a "cd pipeline_data" which was a
system logical for where the file needs to go. This doesn't work as SSL
doesn't appear to understand logicals. I had to change it to "cd
/lda105/pipeline_data" to get it to work.
This breaks my rule that no script/com file should have a real device
name except for sys$manager:logicals.com. I put a remark in the
logicals.com to remind me of the new dependency if that logical changes.

Can you create a command procedure that looks up the logical and
writes out a temporary sftp command procedure containing the hardcoded
current definition ?

That way, there's no permanent file containing the hardcoded definition.

Simon.

[Simon Clubley]

Post by Simon Clubley

Post by jeffrey_dsi
We recently updated a customer to OpenVMS V8.4-2l3 and SSL3 v3.0-13
after many conversations with VSI as to which version of SSL to run.
We have a cron job that produces an xml file and uses sftp to push it to
the VMS system. In the script it did a "cd pipeline_data" which was a
system logical for where the file needs to go. This doesn't work as SSL
doesn't appear to understand logicals. I had to change it to "cd
/lda105/pipeline_data" to get it to work.
This breaks my rule that no script/com file should have a real device
name except for sys$manager:logicals.com. I put a remark in the
logicals.com to remind me of the new dependency if that logical changes.

Can you create a command procedure that looks up the logical and
writes out a temporary sftp command procedure containing the hardcoded
current definition ?
That way, there's no permanent file containing the hardcoded definition.

Oops, sorry, ignore that. I missed the bit where you were pushing it
_onto_ the VMS system.

However, have you tried playing with the cd parameter to try and
force a lookup (for example by trying a leading "/" or something
that looks VMS-like such as "cd PIPELINE_DATA:" ?

Simon.

[jeffrey_dsi]

Post by Simon Clubley

Post by Simon Clubley

Post by jeffrey_dsi
We recently updated a customer to OpenVMS V8.4-2l3 and SSL3 v3.0-13
after many conversations with VSI as to which version of SSL to run.
We have a cron job that produces an xml file and uses sftp to push it to
the VMS system. In the script it did a "cd pipeline_data" which was a
system logical for where the file needs to go. This doesn't work as SSL
doesn't appear to understand logicals. I had to change it to "cd
/lda105/pipeline_data" to get it to work.
This breaks my rule that no script/com file should have a real device
name except for sys$manager:logicals.com. I put a remark in the
logicals.com to remind me of the new dependency if that logical changes.

Can you create a command procedure that looks up the logical and
writes out a temporary sftp command procedure containing the hardcoded
current definition ?
That way, there's no permanent file containing the hardcoded definition.

Oops, sorry, ignore that. I missed the bit where you were pushing it
_onto_ the VMS system.
However, have you tried playing with the cd parameter to try and
force a lookup (for example by trying a leading "/" or something
that looks VMS-like such as "cd PIPELINE_DATA:" ?
Simon.

cd PIPELINE_DATA: fails the same as without the colon. I started an
issue with VSI so we'll see what they say.

Jeff

[Craig A. Berry]

Post by jeffrey_dsi

On 2024-08-20, Simon Clubley

Post by Simon Clubley

Post by jeffrey_dsi
We recently updated a customer to OpenVMS V8.4-2l3 and SSL3 v3.0-13
after many conversations with VSI as to which version of SSL to run.
We have a cron job that produces an xml file and uses sftp to push it to
the VMS system. In the script it did a "cd pipeline_data" which was a
system logical for where the file needs to go. This doesn't work as SSL
doesn't appear to understand logicals. I had to change it to "cd
/lda105/pipeline_data" to get it to work.
This breaks my rule that no script/com file should have a real device
name except for sys$manager:logicals.com. I put a remark in the
logicals.com to remind me of the new dependency if that logical changes.

Can you create a command procedure that looks up the logical and
writes out a temporary sftp command procedure containing the hardcoded
current definition ?
That way, there's no permanent file containing the hardcoded definition.

Oops, sorry, ignore that. I missed the bit where you were pushing it
_onto_ the VMS system.
However, have you tried playing with the cd parameter to try and
force a lookup (for example by trying a leading "/" or something
that looks VMS-like such as "cd PIPELINE_DATA:" ?
Simon.

cd PIPELINE_DATA: fails the same as without the colon. I started an
issue with VSI so we'll see what they say.

Why do you think sftp has anything to do with SSL3? sftp runs over SSH,
not TLS.

[Arne Vajhøj]

Post by Craig A. Berry

Post by jeffrey_dsi

Post by jeffrey_dsi
We recently updated a customer to OpenVMS V8.4-2l3 and SSL3 v3.0-13
after many conversations with VSI as to which version of SSL to run.

cd PIPELINE_DATA: fails the same as without the colon. I started an
issue with VSI so we'll see what they say.

Why do you think sftp has anything to do with SSL3? sftp runs over SSH,
not TLS.

SFTP is not using OpenSSH for TLS - FTP over TLS is FTPS.

But SFTP could use OpenSSL as basic cryptographic library
(AES, RSA etc.).

Arne

[Craig A. Berry]

Post by Arne Vajhøj

Post by Craig A. Berry

Post by jeffrey_dsi

Post by jeffrey_dsi
We recently updated a customer to OpenVMS V8.4-2l3 and SSL3 v3.0-13
after many conversations with VSI as to which version of SSL to run.

cd PIPELINE_DATA: fails the same as without the colon. I started an
issue with VSI so we'll see what they say.

Why do you think sftp has anything to do with SSL3? sftp runs over SSH,
not TLS.

SFTP is not using OpenSSH for TLS - FTP over TLS is FTPS.
But SFTP could use OpenSSL as basic cryptographic library
(AES, RSA etc.).

The OP said, "SSL doesn't appear to understand logicals," but it seems
unlikely OpenSSL, which may very well be used for some cryptographic
calls, is also used to do filename processing for sftp's cd command. We
don't even know if the upgrade to v8.4-2L3 included a switch from
traditional SSH to OpenSSH, which seems more likely to have caused a
switch in behavior. Which log files to examine and which configurations
to check will get you a lot farther if you look at the ones for the
product you're actually using.

We haven't yet heard whether Simon's suggestion of using a leading slash:

cd /pipeline_data

has been tried.

If there has been a switch to OpenSSH, it would be unsurprising if the
cd command encounters the following feature in a way that the old SSH
package didn't:

-----
DECC$DISABLE_TO_VMS_LOGNAME_TRANSLATION

With DECC$DISABLE_TO_VMS_LOGNAME_TRANSLATION enabled, the conversion
routine decc$to_vms will only treat the first element of a UNIX style
name as a logical name if there is a leading slash (/).
-----

[Lawrence D'Oliveiro]

Post by jeffrey_dsi
We recently updated a customer to OpenVMS V8.4-2l3 and SSL3 v3.0-13
after many conversations with VSI as to which version of SSL to run.

All versions of SSL that are called “SSL” are obsolete. All the versions
recommended for use have “TLS” in their name: TLS 1.3 is the current one,
I think some are still using TLS 1.2. Nothing older than that is worth
using any more.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by jeffrey_dsi
We recently updated a customer to OpenVMS V8.4-2l3 and SSL3 v3.0-13
after many conversations with VSI as to which version of SSL to run.

All versions of SSL that are called “SSL” are obsolete. All the versions
recommended for use have “TLS” in their name: TLS 1.3 is the current one,
I think some are still using TLS 1.2. Nothing older than that is worth
using any more.

Protocols that are named SSL are obsolete.

Software that are named SSL (and implementing TLS) is not obsolete.

Arne

[Lawrence D'Oliveiro]

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

Post by jeffrey_dsi
We recently updated a customer to OpenVMS V8.4-2l3 and SSL3 v3.0-13
after many conversations with VSI as to which version of SSL to run.

All versions of SSL that are called “SSL” are obsolete. All the
versions recommended for use have “TLS” in their name: TLS 1.3 is the
current one, I think some are still using TLS 1.2. Nothing older than
that is worth using any more.

Protocols that are named SSL are obsolete.
Software that are named SSL (and implementing TLS) is not obsolete.

SSL v3 is obsolete.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj

Post by Lawrence D'Oliveiro

Post by jeffrey_dsi
We recently updated a customer to OpenVMS V8.4-2l3 and SSL3 v3.0-13
after many conversations with VSI as to which version of SSL to run.

All versions of SSL that are called “SSL” are obsolete. All the
versions recommended for use have “TLS” in their name: TLS 1.3 is the
current one, I think some are still using TLS 1.2. Nothing older than
that is worth using any more.

Protocols that are named SSL are obsolete.
Software that are named SSL (and implementing TLS) is not obsolete.

SSL v3 is obsolete.

SSL V3 protocol is obsolete.

VMS SSL3 kit which is a port of OpenSSL 3.x is not obsolete.

Protocol <> Software

Arne

[Lawrence D'Oliveiro]

Post by Arne Vajhøj
SSL V3 protocol is obsolete.
VMS SSL3 kit which is a port of OpenSSL 3.x is not obsolete.
Protocol <> Software

Ah. That wasn’t clear to me.

OpenSSL 3 is good. It makes it much easier to be your own CA and sign your
own certs, for example.

[Arne Vajhøj]

Post by Lawrence D'Oliveiro

Post by Arne Vajhøj
SSL V3 protocol is obsolete.
VMS SSL3 kit which is a port of OpenSSL 3.x is not obsolete.
Protocol <> Software

Ah. That wasn’t clear to me.

I believe the version number conversion is:

OpenSSL 3.x.y -> VMS SSL3 V3.x-y

Arne

[jeffrey_dsi]

It turns out that the error was in OpenSSH that was also upgraded at the
same time as the switch to SSL3. VSI says the bug is fixed in OpenSSH
V8.9-2i01 along with a lot of other fixes. I am going to start testing
that version next week.

Post by jeffrey_dsi
We recently updated a customer to OpenVMS V8.4-2l3 and SSL3 v3.0-13
after many conversations with VSI as to which version of SSL to run.
We have a cron job that produces an xml file and uses sftp to push it to
the VMS system. In the script it did a "cd pipeline_data" which was a
system logical for where the file needs to go. This doesn't work as SSL
doesn't appear to understand logicals. I had to change it to "cd
/lda105/pipeline_data" to get it to work.
This breaks my rule that no script/com file should have a real device
name except for sys$manager:logicals.com. I put a remark in the
logicals.com to remind me of the new dependency if that logical changes.
Jeff Coffield
www.digitalsynergyinc.com

[Simon Clubley]

Post by jeffrey_dsi
It turns out that the error was in OpenSSH that was also upgraded at the
same time as the switch to SSL3. VSI says the bug is fixed in OpenSSH
V8.9-2i01 along with a lot of other fixes. I am going to start testing
that version next week.

Just curious: Did you try the "cd /pipeline_data" I suggested ?

Simon.

[jeffrey_dsi]

I did try that and it didn't work.

Jeff

Post by Simon Clubley

Post by jeffrey_dsi
It turns out that the error was in OpenSSH that was also upgraded at the
same time as the switch to SSL3. VSI says the bug is fixed in OpenSSH
V8.9-2i01 along with a lot of other fixes. I am going to start testing
that version next week.

Just curious: Did you try the "cd /pipeline_data" I suggested ?
Simon.

[Simon Clubley]

Post by jeffrey_dsi
I did try that and it didn't work.

Thanks for the feedback. Craig posted the reason why I was curious
if it would work.

Simon.

Post by jeffrey_dsi
Jeff

Post by Simon Clubley

Post by jeffrey_dsi
It turns out that the error was in OpenSSH that was also upgraded at the
same time as the switch to SSL3. VSI says the bug is fixed in OpenSSH
V8.9-2i01 along with a lot of other fixes. I am going to start testing
that version next week.

Just curious: Did you try the "cd /pipeline_data" I suggested ?
Simon.

[Stephen Hoffman]

Post by jeffrey_dsi
We recently updated a customer to OpenVMS V8.4-2l3 and SSL3 v3.0-13
after many conversations with VSI as to which version of SSL to run.
We have a cron job that produces an xml file and uses sftp to push it
to the VMS system. In the script it did a "cd pipeline_data" which was
a system logical for where the file needs to go. This doesn't work as
SSL doesn't appear to understand logicals. I had to change it to "cd
/lda105/pipeline_data" to get it to work.
This breaks my rule that no script/com file should have a real device
name except for sys$manager:logicals.com. I put a remark in the
logicals.com to remind me of the new dependency if that logical changes.

Given sftp is built atop ssh, and TLS itself knows ~zilch about cd and
file paths, I'm not sure why any TLS version is involved here.

The OpenSSH version would seem more central to this morass, and maybe
the OpenSSH port isn't playing nice with logical names, as compared
with the older HPE TCP/IP Services ssh stack.

(I haven't updated the local box to the OpenSSH V8.9-1I port — though
OpenSSH 9.8 is current — so no way to check what that links against.
It's possible OpenSSH might.)

(I? In a version string? Seriously?)

See if the installed ssh stack makes a difference, if VSI didn't
already suggest that. Or push over the file and pre-process it on
OpenVMS. Or select a login for the ssh that gets you to the right path.
Otherwise, you're waiting for VSI to fix the bug.