[Info-vax] OpenSSL CSWS-2.2-1

[Dave Froble]

On 4/8/2019 1:23 PM, Stephen Hoffman wrote:
> On 2019-04-07 02:59:52 +0000, Craig A. Berry said:
>
>> On 4/6/19 8:58 PM, Stephen Hoffman wrote:
>>> So we have CSWS, which everybody obviously knows is a web server.
>>
>> Not just a web server, but a secure web server from a company named
>> Compaq that never knew anything about servers or security.
>
> CSWS, SWB, the oddly-named-and-why-are-these-even-separate Apache
> language modules, T4, etc.
> Terms such as LP and "host-based volume shadowing", for that matter.
> LMF, PAKs, etc.

Host based mirroring might be a bit more understood, but volume 
shadowing sure isn't all that mysterious.

LMF and PAKs should just go away.

Usually when a "challenge" is issued, there will be those who pick up 
the gauntlet.  I figured at least two methods to get past the LMF.  No, 
I'm not saying.  It wasn't to actually do so, just to answer the challenge.

Thing is, and it's been said before, LMF isn't to stop piracy.  If 
someone wants it, they will get it.  Just ask Bill Gates about the 
Chinese.  So, all LMF does is harrass those who respect it.  Get VMS in 
front of as many as possible.  Those who will purchase support will do 
so.  Those who won't don't.  No real loss.

> Process has similar issues with the lack of references to "firewall" in
> their Multinet docs, IIRC.
> There's "autogen", which by all appearances neither autos nor gens, and
> with a name that is clear if you knew RSX-11.  Why that even still
> exists is another discussion.

Yeah, I'd like to see some SYSGEN parameters just go away, or by default 
be set so that needing to change them will be rare.  I doubt we'll see 
an x86 server with less than 16 GB of memory, and maybe much more.

> This certainly isn't going to change for existing environments, but
> OpenVMS folks are way too fond of OpenVMS-isms in naming, in
> documentation, and in API designs.
> Common terms are helpful, both to existing users and particularly to new
> users.
>
>>> This particular mess is also why I've commented around the lack of an
>>> API for OpenVMS that masks these differences and that makes creating
>>> a secure network connection rather less of a project than is
>>> currently involved.  I've pointed to Secure Transport and similar
>>> approaches as one of various examples from other platforms that have
>>> sought to reduce or to isolate SSL-level differences from the
>>> application developers.

Please!  And better documentation, and ease, for what is necessary. 
Certificates are obscure, at least I think so, and they aren't any 
better, that I'm aware of, on other platforms.

>>> Alternatives to OpenSSL include NaCl and libtls, among others.
>>
>> Some VMS-friendly wrapper functions might be nice.  But as far as the
>> underlying crypto, it would be unwise for VSI to roll any of that on
>> their own.
>
> Wouldn't suggest home-grown cryptography.  That often ends badly.  As
> for wrapping, that's what the Apple frameworks provide.  Secure
> Transport, the Network Framework, etc., wrap libtls, as well as dealing
> with DNS and sockets and certificates.
>
> https://developer.apple.com/security/
>
> Do I expect VSI to crib Apple here?  No.  I reference this so that folks
> can see what's been happening in the past decade or two; in the era
> since the OpenVMS frameworks have been substantially updated.
>
> And as I've commented elsewhere, go try writing a secure network
> connection using DNS, and self-signed root certificate authority and
> certificates and CSRs, and sockets.  Now work through the failure modes
> and the attacks, and "minor" details such as certificate renewals. Apps
> with errors and vulnerabilities are probably the norm here, too. Now
> make this work with IPv6.
>
> Apple's been rolling all of this right into their networking framework,
> past what Secure Transport provides.  As have other folks, I'd expect.
>
>


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