topic Re: SSL 1.4 breaks running environments in Operating System - OpenVMS

SSL 1.4 breaks running environments

Willem Grooters — Wed, 16 Jun 2010 07:06:41 GMT

I'm using 8.4FT and ran into a problem with PHP: Ident mismatch with SSL$LIBCRYPTO_SHR32, in both PHPSHR and PHP. This seems to be an issue with SSL 1.4; others have downloaded the SSL kit from ITRC, and found remarks in the release notes that it would be incompatible with a lot of (HP-supplied!) products:

LDAP
ENCRYPT (and therefore BACKUP/ENCRYPT)
Stunnel
HP System Management Homepage (HP SMH) for OpenVMS
HP WBEM Services for OpenVMS Integrity servers
HP OpenView Operations Agent for OpenVMS
OpenView Performance Agent (OVPA) for OpenVMS
Secure Web Server
ABS
HP Enterprise Directory
iCAp/nPar (dependent on HP WBEM Services)

For the webserver that I use (WASD), there is no issue since it is supplied as object files and linked locally on installtion. But since the files in MOD_PHP are not supplied that way, they won't work.

Of course, I could install the previous version of SSL on the system and refer to that version for PHP and PHPSHR only, but I learned from an earlier version of PHP that when a shared image was referred to by a logical, this is ignored by PHP: the file MUST reside on SYS$LIBRARY.
I could add a separate directory for SSL 1.3 and add the location to the searchlist of SYS$LIBARY just for PHP, but I consider this a bad idea....

Could be assured, PLEASE, that when a VMS system is upgraded to 8.4, that ALL exsiting applications would still work - without the requirement to relink the applications - since that may not always be possible!

Re: SSL 1.4 breaks running environments

Ian Miller. — Wed, 16 Jun 2010 11:19:39 GMT

More details available over at
http://h71000.www7.hp.com/openvms/products/ssl/ssl.html

and updated versions of various components are appearing in patches.

If you want to use SSL V1.4 then plan it's deployment carefully.

As it appears that OpenVMS V8.4 includes SSL 1.4 then careful planning about upgrading will be needed.

HP SSL is based on OpenSSL.org and the API is not stable at least to version 1.0.0

Re: SSL 1.4 breaks running environments

Volker Halle — Thu, 17 Jun 2010 08:35:13 GMT

Willem,

just after releasing HP SSL V1.4, there now also appeared a security advice against HP SSL V1.3 - what a coincidence ;-(

HPSBOV02540 SSRT090249 rev.1 - HP SSL for OpenVMS, Remote Unauthorized Data Injection, Denial of Service(Dos)

Volker.

Re: SSL 1.4 breaks running environments

Ian Miller. — Thu, 17 Jun 2010 09:11:54 GMT

here is a pointer to that bulletin

http://www.itrc.hp.com/service/cki/docDisplay.do?docId=emr_na-c02227287

Re: SSL 1.4 breaks running environments

Jeremy Begg — Fri, 18 Jun 2010 02:14:22 GMT

Note that updates are appearing for the RTLs and Layered Products affected by this change.

At the time of writing, new versions of ENCRYPT and ACMELDAP are available for download from ITRC.

Regards,
Jeremy Begg

Re: SSL 1.4 breaks running environments

SDIH1 — Tue, 22 Jun 2010 14:21:07 GMT

For OpenSSL, if you cannot link PHP again,there is no alternative than the options you describe (changing logicals around).

Installing the older version will probably not work, I'm not sure what will happen: either it will not install, or it will remove the newer version. OpenSSL is not upward compatible between any version that has different numbers ( 9.6.7 != 9.6.8).

It's a pain.

Re: SSL 1.4 breaks running environments

Carl Bennett_1 — Sat, 16 Oct 2010 15:06:46 GMT

I just realized last night that I'm stuck with this too.

I use WBEM$SERVER (MGMT Agents 3.4) so that I can run the SNMP page without loading Apache (I have pretty strict audit requirements that say no web servers on database servers).

I had been able to throw MGMT Agents 3.4 on Alphas and Itaniums with no issue but now it looks like I'm being forced towards SMH, which pushes me towards apache and I can't go there.

Does anybody know if there's a way to run SMH without starting the Apache server?

I know that there's something newer for Itaniums but I still have a lot of Alpha clients too.

Re: SSL 1.4 breaks running environments

Jan van den Ende — Sun, 17 Oct 2010 10:41:36 GMT

Willem,

You KNEW this beforehand! (Or at least SHOULD have known).
I was sitting in the chair next to you at the Dutch TUD when this was warned about in the "what is new in 8.4" session.
Neihther the audience nor Engineering was happy about it, but if you (have to) follow OpenSource, and OpenSource does not really care about upward compatibility, this is what you get.

But still it is REALLY unsatisfying, of course :-(

Proost.

Have one in me.

jpe

Re: SSL 1.4 breaks running environments

Hoff — Sun, 17 Oct 2010 13:47:07 GMT

It'd be interesting to learn more about the changes to the SSL interfaces involved here, as there do appear to be paths available for establishing the SSL version upgrades more incrementally; without the big-bang upgrade.

If the changes here were strictly API-level changes and whether changed APIs, new APIs, or removed APIs, then the implementation of the upgrade could have easily been handled (differently), and the results would have permitted an incremental SSL upgrade. Which implies that there were more endemic changes involved here. Which makes me curious around the changes.

Lacking the details of the complexity of the API changes (and lacking equally key, though entirely API-tangental details, including available project scheduling and staffing), I'll leave it to VMS Engineering to have made the appropriate design and deployment calls here.

--

FWIW, the OpenSSL code-base hasn't hit their V1.0 release, so they've not locked down their programming interfaces. Without (or even with!) that compatibility statement from the project team, interface changes are a normal part of software development operations with layered products, and have arisen even within VMS itself.

Yes, API compatibility has occasionally gone sideways within VMS itself, such as what happened with the BACKUP API some years back.

These sorts of incompatible changes to tools and APIs are somewhat more typical in a Unix environment, which can be (somewhat counterintuitively) a strength. Maintaining compatibility is not without its costs. (And of all the folks around, the folks in VMS engineering most definitely appreciate the costs of this compatibility.)

Re: SSL 1.4 breaks running environments

Willem Grooters — Sun, 17 Oct 2010 16:34:16 GMT

On the OpenSSL website I found additional information. There have been complaints here as well. It seems the team works toward a 1.0 version and it is agreed that supervision has been lacking - causing this mess. That has to removed first. And even after 1.0 has been released, newer version will be incompatible - once again - with previous one.

So be prepared for even more trouble.

Re: SSL 1.4 breaks running environments

Zia_Ahmad — Wed, 27 Oct 2010 15:31:17 GMT

SSL 1.4 also "broke" ConnectDirect A.K.A NDM under V8.3A during ECO/upgrade activity.
NDM version V3.4-01 ECO-A071209 SP.

Re: SSL 1.4 breaks running environments

Joseph Bettro — Tue, 04 Jan 2011 15:56:17 GMT

Anyone else run into this same issue with OVO v8 agent install on OpenVMS v8.4 integrity?
-------------------------------------------
HP I64VMS VMSSPI V8.0-1: HP OpenView Operations Operating System Smart Plug-In f
or OpenVMS

Read me file is available in sys$specific:[ovo]VMSSPI_README.TXT
Defining OVO$POSIX_ROOT to DSA7:[OVO$FOCDI1.OVO.],DSA7:[OVO$COMMON_IA64.OVO.]
Starting opcactivate utility.

NOTE: opcactivate script will use the values:
OVO Server hostname: HPOM7001WIN
Certificate Server hostname: HPOM7001WIN

%DCL-W-ACTIMAGE, error activating image SSL$LIBSSL_SHR32
-CLI-E-IMGNAME, image file DSA1:[SYS0.SYSCOMMON.][SYSLIB]SSL$LIBSSL_SHR32.EXE
-SYSTEM-F-SHRIDMISMAT, ident mismatch with shareable image

Re: SSL 1.4 breaks running environments

Hoff — Tue, 04 Jan 2011 16:44:11 GMT

Try redirecting the image activations to side copies of the old shareable images via logical name?

Place old copies elsewhere and aim some logical names at it. (Given the file is installed, it'll have to be a trusted logical name in a trusted logical name table, unfortunately.) Or if you're so inclined, you might try patching the OVO images to reference a different name for the file, and use that as a shim to insinuate the older images into the activation path. (Given this is security code, that shim may or may not work.)

Do call HP support, and let them know they apparently have another dependency issue with the SSL patch, if they haven't noticed this case already.

Re: SSL 1.4 breaks running environments

Joseph Bettro — Tue, 04 Jan 2011 17:54:39 GMT

This is brand new system build so unfortunately no prior version of SSl exists. I don't want to take the chance of installing a prior version and breaking some other products. I've got a case open with HP for the OVO install issue...

Thanks