SSL V3

[Dave Froble]

Just got an email from VSI, their version of SSL V3 is now available. This
should be a good thing, bringing some of the latest SSL stuff to VMS.

Some good news.

Now if only a decent TCP/IP was available.

Still, lots of hope for VMS capabilities. Be nice if some new customers came along.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Arne Vajhøj]

On 2/15/2022 10:56 PM, Dave Froble wrote:
> Just got an email from VSI, their version of SSL V3 is now available.
> This should be a good thing, bringing some of the latest SSL stuff to VMS.

I assume OpenSSL software version 3.x and not SSL protocol version 3.0.

OpenSSL 3.x is latest and greatest. SSL 3.0 is very much obsolete and
deprecated - only TLS 1.2 and 1.3 should be used - and obviously OpenSSL
3.x support those.

> Still, lots of hope for VMS capabilities.  Be nice if some new customers
> came along.

Yes!!

Arne

[Craig A. Berry]

On 2/16/22 7:31 AM, Arne Vajhøj wrote:
> On 2/15/2022 10:56 PM, Dave Froble wrote:
>> Just got an email from VSI, their version of SSL V3 is now available.
>> This should be a good thing, bringing some of the latest SSL stuff to
>> VMS.
>
> I assume OpenSSL software version 3.x and not SSL protocol version 3.0.
>
> OpenSSL 3.x is latest and greatest. SSL 3.0 is very much obsolete and
> deprecated - only TLS 1.2 and 1.3 should be used - and obviously OpenSSL
> 3.x support those.

Yes, they are calling it OpenSSL v3.0-1, which presumably corresponds to
OpenSSL 3.0.1. The product name is SSL3. Since binary compatibility is
now guaranteed for anything with the same major version number, we
should not have a repeat of the product naming madness that resulted in
SSL111.

[Arne Vajhøj]

Retain open source name and VMSify version number from x.y.z to x.y-z is
all fine. No confusion.

I just wanted to ensure that everyone know the difference between
OpenSSL 3.x and SSL 3 - the SSL 3 protocol is banned everywhere
as insecure (or at least should be).

Arne

[Simon Clubley]

I wish people would not rename an open source product with a
slightly different VMS-specific name. It's bloody confusing
and completely unnecessary. :-(

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

[Simon Clubley]

On 2022-02-16, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> On 2/16/2022 8:52 AM, Craig A. Berry wrote:
>>
>> Yes, they are calling it OpenSSL v3.0-1, which presumably corresponds to
>> OpenSSL 3.0.1.  The product name is SSL3.  Since binary compatibility is
>> now guaranteed for anything with the same major version number, we
>> should not have a repeat of the product naming madness that resulted in
>> SSL111.
>
> Retain open source name and VMSify version number from x.y.z to x.y-z is
> all fine. No confusion.
>

What about 6 months from now when people are asking if this is a
patch for v3.0 or is really a renamed v3.0.1 ?

[Arne Vajhøj]

On 2/16/2022 9:08 AM, Simon Clubley wrote:
> On 2022-02-16, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 2/16/2022 8:52 AM, Craig A. Berry wrote:
>>> Yes, they are calling it OpenSSL v3.0-1, which presumably corresponds to
>>> OpenSSL 3.0.1.  The product name is SSL3.  Since binary compatibility is
>>> now guaranteed for anything with the same major version number, we
>>> should not have a repeat of the product naming madness that resulted in
>>> SSL111.
>>
>> Retain open source name and VMSify version number from x.y.z to x.y-z is
>> all fine. No confusion.
>
> What about 6 months from now when people are asking if this is a
> patch for v3.0 or is really a renamed v3.0.1 ?

Then somebody tell them that VMS version number convention is
not major.minor.release.patchlevel but
major.minor-release ECOpatchlevel.

Arne

[Jan-Erik Söderholm]

It's the same as Oracle Rdb 7.4.1.1.0 being called V7.4-110 in VMS itself.

So, Simon, what should it be called? My understading is that there are
rules used by VMS on how to format a vesion number.

[Stephen Hoffman]

On 2022-02-16 03:56:17 +0000, Dave Froble said:

> Just got an email from VSI, their version of SSL V3 is now available.
> This should be a good thing, bringing some of the latest SSL stuff to
> VMS.

OpenSSL 3.0.1 (SSL3 kit on OpenVMS, as differentiated from SSLv3) and
OpenSSH 8.8 both.

> Some good news.

Ayup. Definitely.

> Now if only a decent TCP/IP was available.

Getting more current SSL and more current ssh are a big part of that,
with more networking work and more networking integration work awaiting
VSI.

The network configuration tool is unnecessarily complex and error-prone
and unintegrated, for instance. It's blown up on me several times over
recent months, crashing out with missing symbols. Not that getting any
of the existing network configs over into some newer scheme will be
trivial, or will even be attempted, or won't otherwise run afoul of
existing UIC allocations or usernames selected. That OpenSSL 3.0.1 is
correctly but confusingly known as the SSL3 kit on OpenVMS—as
differentiated from the ancient SSLv3 version—is another area that
would disappear with networking integration, too. IP networking and SSL
shouldn't be separate installation kits or otherwise visible to an
installer. Not any more. But VSI necessarily has much bigger
priorities, not the least of which is the completion of the x86-64
port. Fixing an ever-more complex management UI likely isn't at the top
of any schedule or any priority list, but it is a cost that accretes.




--
Pure Personal Opinion | HoffmanLabs LLC

[Mark Daniel]

On 16/2/22 2:26 pm, Dave Froble wrote:
> Just got an email from VSI, their version of SSL V3 is now available.

Dave, would you mind posting the relevant section(s) of this advice.

I have been building OpenSSL 3.0.0 and 3.0.1 since release and currently
have an unresolved performance issue open

https://github.com/openssl/openssl/issues/16552

As VSI have released

VSI X86VMS SSL111 V1.1-1MA Full LP Install Val 04-FEB-2022

only in the last couple of weeks, the announcement seems a little odd.

> This should be a good thing, bringing some of the latest SSL stuff to VMS.
>
> Some good news.
>
> Now if only a decent TCP/IP was available.
>
> Still, lots of hope for VMS capabilities.  Be nice if some new customers
> came along.

--

Anyone, who using social-media, forms an opinion regarding anything
other than the relative cuteness of this or that puppy-dog, needs
seriously to examine their critical thinking.

[Mark Daniel]

On 17/2/22 2:44 am, Mark Daniel wrote:
> On 16/2/22 2:26 pm, Dave Froble wrote:
>> Just got an email from VSI, their version of SSL V3 is now available.
>
> Dave, would you mind posting the relevant section(s) of this advice.

Thanks but don't bother. Found it myself.

https://vmssoftware.com/products/ssl3/

[Stephen Hoffman]

On 2022-02-16 16:44:54 +0000, Mark Daniel said:

> On 16/2/22 2:26 pm, Dave Froble wrote:
>> Just got an email from VSI, their version of SSL V3 is now available.
>
> Dave, would you mind posting the relevant section(s) of this advice.
>
> I have been building OpenSSL 3.0.0 and 3.0.1 since release and
> currently have an unresolved performance issue open
>
> https://github.com/openssl/openssl/issues/16552
>
> As VSI have released
>
> VSI X86VMS SSL111 V1.1-1MA Full LP Install Val 04-FEB-2022
>
> only in the last couple of weeks, the announcement seems a little odd.

I'd expect to see both OpenSSL v1.1-1 / SSL111 / OpenSSL 1.1.1 and
OpenSSL v3.0-1 / SSL3 / OpenSSL 3.0.1 released in parallel for a while
and each with occasional updates, to give folks the opportunity to
migrate apps to OpenSSL v3.0-1 / SSL3 / OpenSSL 3.0.1.

The OpenSSL v3.0-1 release notes make it very clear that this is to be
a rolling migration, and that "under no circumstances should [OpenSSL
1.1.1] be removed". That advice will undoubtedly change as VSI and
third-parties and end-users all complete the migration.

The newly-announced OpenSSH 8.8 kit is currently available (only) for
OpenVMS x86-64 V9.1A and later.

[Arne Vajhøj]

On 2/16/2022 11:14 AM, Mark Daniel wrote:
> On 16/2/22 2:26 pm, Dave Froble wrote:
>> Just got an email from VSI, their version of SSL V3 is now available.
>
> Dave, would you mind posting the relevant section(s) of this advice.
>
> I have been building OpenSSL 3.0.0 and 3.0.1 since release and currently
> have an unresolved performance issue open
>
> https://github.com/openssl/openssl/issues/16552
>
> As VSI have released
>
> VSI X86VMS SSL111 V1.1-1MA    Full LP   Install    Val 04-FEB-2022
>
> only in the last couple of weeks, the announcement seems a little odd.

Their web site got:

https://vmssoftware.com/products/ssl3/

Arne

[Craig A. Berry]

On 2/16/22 10:14 AM, Mark Daniel wrote:
> On 16/2/22 2:26 pm, Dave Froble wrote:
>> Just got an email from VSI, their version of SSL V3 is now available.
>
> Dave, would you mind posting the relevant section(s) of this advice.

I'm not sure what advice you refer to, but the announcement did
emphasize that people should not try to uninstall SSL111 and that the
3.x kit was being made available so people could start investigating
compatibility and migration.

> I have been building OpenSSL 3.0.0 and 3.0.1 since release and currently
> have an unresolved performance issue open
>
> https://github.com/openssl/openssl/issues/16552
>
> As VSI have released
>
> VSI X86VMS SSL111 V1.1-1MA    Full LP   Install    Val 04-FEB-2022
>
> only in the last couple of weeks, the announcement seems a little odd.

I think the only news here for you is that other people who rely on an
installation kit can now find the problems you've already found by
building your own from source.

[Galen]

Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
>
> The OpenSSL v3.0-1 release notes make it very clear…
>
[to me] that I have no reason to envy anyone the task of dealing with this
hash (that is, mess).

[Stephen Hoffman]

The upgrade from OpenSSL 0.9.x to OpenSSL 1—known as SSL V1.3 to SSL
V1.4 on OpenVMS, back when the OpenVMS versions didn't parallel the
upstream versions—required everything else linked with SSL to upgrade.
Locally, there were a couple of other products affected, but some sites
had a half-dozen or more apps or tools that needed upgrades parallel to
the SSL V1.4 upgrade.

That this area is still a bit of a hash—though somewhat less so, as a
rolling upgrade of apps and products is now usually possible—is also
why there are somewhat more stable networking frameworks available on
some other platforms. Some of those frameworks include easier handling
of the rest of of app networking; of DNS or mDNS, IPv4 and IPv6
transparency, and related error handling and recovery and
authentication.

[Ponders whether the existing multi-version support within OpenVMS
would permit a parallel installation of LibreSSL and its libtls API, as
an alternative to OpenSSL and its API on OpenVMS.]

[Mark Daniel]

On 17/2/22 3:08 am, Craig A. Berry wrote:
>
> On 2/16/22 10:14 AM, Mark Daniel wrote:
>> On 16/2/22 2:26 pm, Dave Froble wrote:
>>> Just got an email from VSI, their version of SSL V3 is now available.
>>
>> Dave, would you mind posting the relevant section(s) of this advice.
>
> I'm not sure what advice you refer to, but the announcement did
> emphasize that people should not try to uninstall SSL111 and that the
> 3.x kit was being made available so people could start investigating
> compatibility and migration.

See that now I've installed the kit.

>> I have been building OpenSSL 3.0.0 and 3.0.1 since release and
>> currently have an unresolved performance issue open
>>
>> https://github.com/openssl/openssl/issues/16552
>>
>> As VSI have released
>>
>> VSI X86VMS SSL111 V1.1-1MA    Full LP   Install    Val 04-FEB-2022
>>
>> only in the last couple of weeks, the announcement seems a little odd.
>
> I think the only news here for you is that other people who rely on an
> installation kit can now find the problems you've already found by
> building your own from source.

The released kit contains the described performance issue.

https://github.com/openssl/openssl/issues/16552

$ @build_sesola3.com 1
$ mcr []sesola3
OpenSSL 1.1.1k 25 Mar 2021
value: 1
ELAPSED: 0 00:00:00.20 CPU: 0:00:00.19 BUFIO: 4 DIRIO: 7 FAULTS: 158
$ @build_sesola3.com 3
$ mcr []sesola3
OpenSSL 3.0.1 14 Dec 2021
value: 1
ELAPSED: 0 00:00:06.63 CPU: 0:00:06.58 BUFIO: 4 DIRIO: 7 FAULTS: 237

On the BRIGHT SIDE - VSI being proactive on these essential tools is a
refreshing change from the previous incumbents' approach of only
releasing at version EOL or when containing *absolutely* critical fixes.

Might be able to give the WASD-specific builds away if they can keep
this up.

[Simon Clubley]

On 2022-02-16, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
>
> It's the same as Oracle Rdb 7.4.1.1.0 being called V7.4-110 in VMS itself.
>

That's just yucky. :-)

However, that's also not something which is known by a different name
on (say) Linux.

> So, Simon, what should it be called? My understading is that there are
> rules used by VMS on how to format a vesion number.

VMS isn't the centre of the world anymore Jan-Erik.

Quite a lot of what VMS is running these days was written on another
operating system and to avoid confusion on VMS, the VMS name should
be as close to the real name as possible.

If VSI make some VMS-specific changes _then_ they can call it an ECO
or create a VMS format -release. Until then it should be the real
version of the project that is used.

In addition to version number confusion, open source projects in
the past have been renamed for no good reason on VMS (Apache becoming
CSWS would be one good example). I hope VSI _never_ start doing that.

[Simon Clubley]

On 2022-02-16, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
>
> I'd expect to see both OpenSSL v1.1-1 / SSL111 / OpenSSL 1.1.1 and
> OpenSSL v3.0-1 / SSL3 / OpenSSL 3.0.1 released in parallel for a while
> and each with occasional updates, to give folks the opportunity to
> migrate apps to OpenSSL v3.0-1 / SSL3 / OpenSSL 3.0.1.
>

Is it 3.0.0 or 3.0.1 that's being shipped by VSI ?

The release notes claim 3.0.1 but the VSI website points to the old 3.0.0
releases at https://www.openssl.org/source/old/3.0/

Also, the kit name is SSL3, but given that there are multiple SSL libraries
available, that should really be OPENSSL3. This might not matter to those
of us who keep a mental matrix of VMS versions to real versions, but
to others, it's just another source of unnecessary confusion about what
exactly is running on VMS.

[Jan-Erik Söderholm]

Den 2022-02-16 kl. 20:19, skrev Simon Clubley:
> On 2022-02-16, Jan-Erik Söderholm <jan-erik....@telia.com> wrote:
>>
>> It's the same as Oracle Rdb 7.4.1.1.0 being called V7.4-110 in VMS itself.
>>
>
> That's just yucky. :-)

Maybe, but it is nt a problem as such.

>
> However, that's also not something which is known by a different name
> on (say) Linux.
>
>> So, Simon, what should it be called? My understading is that there are
>> rules used by VMS on how to format a vesion number.
>
> VMS isn't the centre of the world anymore Jan-Erik.

What has that to do with internal rules for formatting a version number?

>
> Quite a lot of what VMS is running these days was written on another
> operating system and to avoid confusion on VMS, the VMS name should
> be as close to the real name as possible.

And what if that is simply no technically possible?
How much effort do you think should be put into *this* quite
made-up "problem"?

>
> If VSI make some VMS-specific changes _then_ they can call it an ECO
> or create a VMS format -release. Until then it should be the real
> version of the project that is used.

And what if that simply isn't possible?

[Mark Daniel]

On 17/2/22 4:06 am, Mark Daniel wrote:

8< snip 8<>>> I have been building OpenSSL 3.0.0 and 3.0.1 since release

and
>>> currently have an unresolved performance issue open
>>>
>>> https://github.com/openssl/openssl/issues/16552
>>>
>>> As VSI have released
>>>
>>> VSI X86VMS SSL111 V1.1-1MA    Full LP   Install    Val 04-FEB-2022
>>>
>>> only in the last couple of weeks, the announcement seems a little odd.
>>
>> I think the only news here for you is that other people who rely on an
>> installation kit can now find the problems you've already found by
>> building your own from source.
>
> The released kit contains the described performance issue.
>
> https://github.com/openssl/openssl/issues/16552
>
> $ @build_sesola3.com 1
> $ mcr []sesola3
> OpenSSL 1.1.1k  25 Mar 2021
> value: 1
> ELAPSED: 0 00:00:00.20 CPU: 0:00:00.19 BUFIO: 4 DIRIO: 7 FAULTS: 158
> $ @build_sesola3.com 3
> $ mcr []sesola3
> OpenSSL 3.0.1 14 Dec 2021
> value: 1
> ELAPSED: 0 00:00:06.63 CPU: 0:00:06.58 BUFIO: 4 DIRIO: 7 FAULTS: 237

8< snip 8<

The recent OpenSSL 3.0.2 release does not address the issue, in fact
it's gone backwards. Freshly built and executed.

$ mcr []sesola3.EXE

OpenSSL 1.1.1k 25 Mar 2021
value: 1

ELAPSED: 0 00:00:00.19 CPU: 0:00:00.19 BUFIO: 4 DIRIO: 7 FAULTS: 159

$ mcr []sesola3.EXE

OpenSSL 3.0.1 14 Dec 2021
value: 1

ELAPSED: 0 00:00:06.50 CPU: 0:00:06.39 BUFIO: 4 DIRIO: 7 FAULTS: 142

$ mcr []sesola3.EXE
OpenSSL 3.0.2 15 Mar 2022
value: 1
ELAPSED: 0 00:00:08.33 CPU: 0:00:08.29 BUFIO: 4 DIRIO: 7 FAULTS: 155

[Mark Daniel]

Quoting from the github thread

https://github.com/openssl/openssl/issues/16552

**** NO CHANGE IN BEHAVIOUR OVER THREE ITERATIONS AND EIGHT MONTHS *****

$ mcr []sesola3
OpenSSL 1.1.1n 15 Mar 2022
value: 1
ELAPSED: 0 00:00:00.23 CPU: 0:00:00.22 BUFIO: 4 DIRIO: 8 FAULTS: 205

$ mcr []sesola3
OpenSSL 3.0.3 3 May 2022
value: 1
ELAPSED: 0 00:00:06.16 CPU: 0:00:06.14 BUFIO: 4 DIRIO: 7 FAULTS: 153

[Mark Daniel]

Well it's not going to get any faster. Apparently this overhead is
inherent in OpenSSL 3.0.n

"There were significant fixes in the internal algorithm fetching caching
which impacts certificate decoding. Unfortunately it will be very hard
if not impossible to progress further. The decoding is much more complex
process in openssl-3.0 in comparison to openssl-1.1.1."

The solution for multiple service initializations is (where possible)
instead of SSL_CTX_load_verify_locations() for every SSL context to
perform this for only the first, then SSL_CTX_set1_cert_store() for
subsequent contexts. Thanks Richard Levitte.

[Dave Froble]

On 2/15/2022 10:56 PM, Dave Froble wrote:

> Just got an email from VSI, their version of SSL V3 is now available. This
> should be a good thing, bringing some of the latest SSL stuff to VMS.
>
> Some good news.
>
> Now if only a decent TCP/IP was available.
>
> Still, lots of hope for VMS capabilities. Be nice if some new customers came
> along.
>

New from VSI this morning:

VSI SSL111 V0101-1O-1 (Secure Sockets Layer) is based on the OpenSSL V1.1.1o
release from the OpenSSL Group.

Perhaps the bad old days of neglect from HP are now behind us?

[Robert A. Brooks]

On 6/28/2022 9:59 AM, Dave Froble wrote:

> New from VSI this morning:
>
> VSI SSL111 V0101-1O-1 (Secure Sockets Layer) is based on the OpenSSL V1.1.1o
> release from the OpenSSL Group.
>
> Perhaps the bad old days of neglect from HP are now behind us?

I do think that we (VSI) have made a much better effort at providing open source
work than HP(E) ever did for VMS.

--
-- Rob

[Hans Bachner]

Definitely. Thumbs up!

Hans.

[Stephen Hoffman]

On 2022-06-28 13:59:17 +0000, Dave Froble said:

> New from VSI this morning:
>
> VSI SSL111 V0101-1O-1 (Secure Sockets Layer) is based on the OpenSSL
> V1.1.1o release from the OpenSSL Group.

OpenSSL versions released so far this year:

21-Jun-2022 OpenSSL 3.0.4 is now available, including bug and security fixes
21-Jun-2022 OpenSSL 1.1.1p is now available, including bug and
security fixes
03-May-2022 OpenSSL 3.0.3 is now available, including bug and security fixes
03-May-2022 OpenSSL 1.1.1o is now available, including bug and
security fixes
15-Mar-2022 OpenSSL 3.0.2 is now available, including bug and security fixes
15-Mar-2022 OpenSSL 1.1.1n is now available, including bug and
security fixes

Here are the known flaws in 1.1.1o:
https://www.openssl.org/news/secadv/20220621.txt

AFAIK, that rehash feature is not automatically executed on OpenVMS,
but VSI would know best.

Everything prior to 1.1.1 is considered out of support by OpenSSL.