[Info-vax] One possible market for VMS: secure credit card
David Froble
davef at tsoft-inc.com
Tue Mar 24 17:32:45 EDT 2015
Stephen Hoffman wrote:
> On 2015-03-24 14:11:55 +0000, David Froble said:
>
>> This topic isn't about users. This topic is about VMS possibly
>> providing a better environment for security. That shirley is a techie
>> issue.
>
> Surprisingly to those in the security world, usually not. Most folks
> don't really care about security. Usually right up until they are
> breached. Most folks care far more about getting something done, and in
> a reasonably low-hassle and cost-effective way, and heading off to do
> something else. Security and passwords and the rest? That's insurance,
> as far as most folks are concerned.
>
> If you want to look at security in the current environment, OpenVMS
> arguably needs some substantial upgrades to deal with more modern
> attacks — if folks are unfamiliar with "W^X", "ROP", "canaries" or
> "ASLR" jargon in this context, see the URLs below. Put another way,
> the security attacks have changed a whole lot in recent years. I'd
> expect OpenVMS would need to migrate to encrypted and authenticated
> transports everywhere, which likely means that DECnet, VPM, SYSMAN,
> NISCS and FTP are overhauled and/or disappear from the baseline
> configurations, SMH gets gone over, OpenSSL gets updated to 1.0.2
> current and/or maybe replaced with LibreSSL, CDSA probably gets replaced
> and which might mean more kit-signing work and potentially also
> authenticated and encrypted patch server access, SYSUAF and
> $hash_password get reworked to add support modern cryptographic hashes,
> certificate stores and IPSec and VPNs get added, internet-facing pieces
> such as the lack of encrypted POP and IMAP transports and the rest of
> the IP-related tools and packages get overhauled, ACME LOGINOUT becomes
> the default, and among a number of other changes that would be somewhere
> between desirable and necessary.
>
> <https://en.wikipedia.org/wiki/W%5EX>
> <https://en.wikipedia.org/wiki/Return-oriented_programming>
> <https://en.wikipedia.org/wiki/Address_space_layout_randomization>
> <https://en.wikipedia.org/wiki/Stack_buffer_overflow>
>
When I first took a look at OpenSSL, it was very confusing to me. The
main reason is because whoever decided to implement it doesn't think
very much like me. (Ok, get in your jabs now ...)
If I was designing this stuff, I'd keep things separate. Communications
would be just that, communications. Encryption also would be self
contained. None of this mixing. Nor do I have any idea whether my
method would have inherent security flaws.
Now, if the encryption was a separate thing, DECnet, TCP/IP, and such
then would not need any security work. It would be up to an application
to perform an encryption handshake, encrypt data, and the communications
would send and receive data, handshake, and such.
Maybe the above would be feasible for DECnet, since that most likely
would be VMS to VMS. I fear it is not feasible for other
communications, since the rest of the world has already decided that
communications and encryption will be joined in a single product.
Nor am I adverse to building encryption into DECnet, and other things.
I've learned to conform to the rest of the world ....
But not C ....
More information about the Info-vax
mailing list