APACHE CSWS V2.2 SSL V1.4 2048 certificate SHA1

[Peter Barkas]

 CSWS works fine with a 2048bit md5 self signed certificate but I was trying to test a self signed certificate using SHA1 and in the process discovered that it appears that APACHE$MENU is running an older version of OpenSSL.

After running SSL option from APACHE$MENU:

$ openssl

OpenSSL> version

OpenSSL 0.9.7d 17 Mar 2004

SSL for OpenVMS V1.2 Nov 3 2004.

$ ru ssl$root:[alpha_exe]openssl

OpenSSL> version

OpenSSL 0.9.8h 28 May 2008

SSL for OpenVMS T1.4 Mar 18 2010.

OpenSSL>

I think that SSL used to be installed in the APACHE directory but now insists on being installed on the system disk.

According to the release notes:

"Apache 2.2 is built using the OpenSSL Version 0.9.8h"

Is there something wrong with the setup here or is this a "feature" of my configuration, APACHE on non-system ODS-5 disk, OpenSSL on system disk ODS-2 or is this a "feature" of the latest  CSWS SSL combination?

[Peter Barkas]

Thank you for the response.

"The HP SSL product is installed where you tell it to be installed."

 - Indeed. I am familiar with the /dest qualifier but it has limited application with the latest release:

Configuring HP AXPVMS SSL V1.4-332: SSL for OpenVMS Alpha V1.4 (Based on OpenSSL 0.9.8h)

© Copyright 208 Hewlett-Packard Development Company, L.P.

The /DESTINATION qualifier is not supported with SSL V1.4

As of SSL V1.4, the SSL product must be installed on the system disk.

If you specified a location other than the system disk with the use of the

qualifier /DESTINATION, it is recommended that you stop the installation

and restart it with the following command:

$ PRODUCT INSTALL SSL

Yes, I can modify the DCL myself but in my opinion that is what we pay HP to do.

CSWS ships with out of date OpenSSL components and the APACHE menu creates symbols such as "OpenSSL" that point at the out of date version.

"OpenSSL is not a stable product with a reliable interface."

I am aware of the problems relating to lack of backward compatibility with recent OpenSSL releases, however, I am not installing or using OpenSSL I am installing and using HP OpenSSL.

"If the old OPENSSL.EXE still does the job"

Then it wouldn't have been necessary for a new release.

There are changes to the self signed certificate feature in the new release.

"Don't worry. Be happy"

I have given up worrying about OpenVMS, but I am not happy.

[Hoff]

Some background: the HP SSL package upgrade was not handled in a way that would permit the two versions of the SSL client interfaces to operate in parallel and this permit a staged upgrade from the older SSL implementation and APIs to the newer; rather than deploying a second shareable image and interface and the ability to select the appropriate shareable interface within the image activator, or via logical name, the upgrade replaced the shareable images.  (This akin to how multiversion Rdb works, for instance.)  With the current implementation, you're either running the old SSL bits and the older bugs and vulnerabilities, or running the new bits, and if you're running the new bits, then your applications need to have been rebuilt to use the new bits. 

I don't know off-hand if the newer HP SSL version is proof against The BEAST attack, or other recent SSL attacks.  (Barring a statement to the contrary or some time spent digging around in the session initialization and protocol support details, I'd tend to assume that it is vulnerable.  

OpenSSL did release their 1.0.0 version in March, 2010, which implies the interfaces may have stabilized.  They're at 1.0.0e right now.  Even if the 1.0.0 APIs are not stable (and I'd assume at least additions, and would still plan for API changes), managing parallel APIs can be entirely feasible on OpenVMS and would allow a staged deployment.  (And given the OpenSSL release history, it would be prudent to assume a (more) rapid release cycle irrespective of any API changes.)  But this is for the folks at HP that are managing the SSL package; there's not much a customer can do, short of porting the code to VMS (again).  (While the OpenSSL source code is open source, there's no requirement within its licenses to release the source code; either HP would have to open their port, or it would be a re-port.)

Beyond the discussion of SSL, the version of Apache used within CSWS is a down-revision 2.0 series (Apache is at 2.2.21) and earlier versions are vulnerable (eg: the killapache DoS), and the path toward that remediation involves managing a newer Apache port and tool chain yourself, moving to WASD or (if and as available) another web server (nginx was not available on VMS, when last I looked), bringing together enough of a community to manage and maintain an Apache port in-house or within in the user community, or migrating to a different front end.  Apache hasn't released a killapache fix for the 2.0 series yet, though the 2.2 series does contain a fix.  There are workarounds discussed in CVE-2011-3192.)

Complicating all of this, the HP software package version numbers don't track the open-source versions.

My longstanding recommendation: don't expose OpenVMS to the Internet.

And FWIW, this isn't the first time that Peter Barkas has breached this and related issues with the web-facing tool chains on OpenVMS; this Securing HP SWS Apache to DoD DISA STIG requirements and security has clearly been an on-going issue at his site.  I've posted product version information in that thread, and there are related discussions there.

The options are unchanged from that earlier discussion: continue to wait for HP to port an update, or for a third-party to make available a newer port.  Perform or coordinate a port of the web-facing tools yourself.  Or migrate parts or all of your front-end or your environment to an operating system platform with the tools that meet or exceed your security needs.

[Peter Barkas · Accepted solution]

Summary of pertinent information.

HP CSWS APACHE$MENU option 5 Run OpenSSL Certificate tool uses a parochial out of date version of SSL rather than the currently installed HP OpenSSL package.

This may cause confusion as symbols created by running APACHE$MENU point to the CSWS version of OpenSSL, but probably this is harmless.

To use the latest HP OpenSSL package for, for example, generating self signed certificates for use with APACHE one may choose either to modify the APACHE$MENU procedure oneself or access the software directly.