Hello info-WASD.

Updated server code and object archive for the WASD SSL functionality.

This bugfixes (and refines) SSL/TLS protocol version configuration. 
Previously SSLv2 and SSLv3 were needed to activate TLSv1 (and TLSv1.1 and
TLSv1.2).  This is not only undesirable, it is broken.  Rather than distract
you with the detail right here I've added an explanation** at the end of this
message.  Although WASD v10.4.0 should be released within a small number of
months, this update is important enough for some sites to warrant release
earlier.  The update is suitable only for v10.3.n.  Be sure to check the
archive notes using UPZIP -z.

The archive can be download from the usual location

  http://wasd.vsm.com.au/wasd/

These contain platform-specific object modules allowing link-only updates.

Restore to the WASD location and update the SSL.

  $ @WASD_FILE_DEV
  $ SET DEFAULT WASD_ROOT:[000000]
  $ UNZIP location:SESOLA141101-<arch>.ZIP
  $ @UPDATE SSL
  $ INSTALL REPLACE WASD_EXE:HTTPD_SSL.EXE
  $ HTTPD/DO=RESTART=NOW

If compiling (rather than linking) during the update, the UNZIP step may be
modified to

  $ UNZIP location:SEESOLA141101-<arch>.ZIP *.C *.H

Other platforms in a mixed architecture cluster need to be updated as well. 
If compiling the update, just move to the next platform and repeat ignoring
the third step.  If using the object modules for a link-only update, the
entire process is required for each platform.

The server release number remains the same (i.e. 10.3.0) but the server
identification string shows an additional value appended

  "HTTPd-WASD/10.3.0 OpenVMS/IA64 SSL/141101"

Also available from the download site is an updated WASD (Open)SSL package
built from the latest OpenSSL v1.0.1j release.  This can be updated in
conjunction with the server.

Cheers, Mark.

**Narrative regarding this update:

Over the past couple of months the anomaly of having TLS protocol only
available when SSLv2 is enabled (?!) has puzzled and disturbed myself, and a
couple of WASD sites administrators, eventually eventually resulting in
identification a problem with WASD's use of the OpenSSL protocol methods.

When WASD started with SSLeay (1998), then into OpenSSL (1999), there was
SSLv3 and an already deprecated SSLv2.  WASD supported options to service one
or other or both.  If you chose both, and as you can only bind one protocol
method to one (Open)SSL context, you needed to bind to function
SSLv23_method() which handled both.  It would appear that over time the
SSLv23_method() has crept in functionality to be *the* gateway to all
OpenSSL-supported SSL methods (protocol versions).

  http://wiki.openssl.org/index.php/Manual:SSL_CTX_new(3)

I'm inclined to add a smiley and/or a frowny here.

WASD has not kept up with this creep.  So this update addresses the issue
where multiple protocol versions are configured by continuing to use
SSLv23_method() while ensuring then that all protocols not explicitly
required are optioned off.

The update also defaults WASD to use only TLS protocols (currently TLSv1,
TLSv1.1 and TLSv1.2).  SSLv2 long deprecated (and not defaulted since v10.1),
and now SSLv3 no longer considered best-practice post-POODLE.

  https://www.openssl.org/~bodo/ssl-poodle.pdf
  https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/
  http://security.stackexchange.com/questions/70719/ssl3-poodle-vulnerability

Of course YMMV and unless handling sensitive communication all this may be a
bit academic.  I particularly enjoyed one comment, "... it is still
considerably easier to simply lure the poor sod on a fake copy of their bank
site. Cryptographic attacks are neat, but they involve more effort than
exploiting the bottomless well of user's gullibility."

The update also (attempts) to refine SSL protocol and options configuration
while not breaking backwards compatibility.

Checking whether a specific protocol version is enabled on a site:

  $ openssl s_client -ssl2 -host <host name or address> -port 443
  $ openssl s_client -ssl3 -host <host name or address> -port 443
  $ openssl s_client -tls1 -host <host name or address> -port 443
  $ openssl s_client -tls1_1 -host <host name or address> -port 443
  $ openssl s_client -tls1_2 -host <host name or address> -port 443
  $ openssl s_client -host <host name or address> -port 443

Version log, additional comment, and general technical whatnot can be found
in the source code for those so inclined ...

  http://wasd.vsm.com.au/wasd_root/SRC/HTTPD/sesola.c