Using SSL with sockets on VMS

[David Froble]

I've got some applications using socket communications, using the system services interface on VMS.

My new task is to enable the use of SSL with select socket communications.

My plan is to determine the requirement for a secure connection when a listener gets a connection request, then open a communications socket using the requested protocols, if that particular protocol is allowed. (Whether my plan is viable, I have yet to discover.)

My problem is finding any documentation on the use of SSL with sockets.

I have looked at the latest copy of "HP TCP/IP Services for OpenVMS Sockets API and System Services Programming" on the documentation site, and cannot find any reference to SSL.

If someone could direct me to appropriate documentation, it would be appreciated. (My web search skills are very poor, and, I do not have a high speed connection.)

If someone could also provide some helpful information on set-up of SSL on VMS V8.3, things needed to be done, and such, that also would be appreciated.

[Richard Whalen]

The SSL libraries are a port of OpenSSL and you can find online documentation at http://www.openssl.org/docs/
O'Reilly publishes a good book on using OpenSSL: Network Security with OpenSSL. http://www.amazon.com/Network-Security-OpenSSL-John-Viega/dp/059600270X/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1208985385&sr=8-1

You may have to write your own BIO routines if you exchange some I/O before deciding that the connection should be encrypted.

[Steven Schweda]

If you're desperate for some example code, I
believe that (my) wget for VMS has some (and
may even work). I haven't really looked at
it, but it seems to be there, and I believe
that I did a couple of "https://" tests (long
ago).

[David Froble]

I'm not working in C. The OpenSSL documentation sort of implies that I need C type header file(s).

But my questions are a bit more basic (sic) than how to use the SSL routines.

Does an application actually have to call the various SSL routines to encrypt and decrypt? I was sort of hoping that SSL was used by TCP/IP, such that I'd set a flag on a socket, and TCP/IP would transparently do the SSL stuff. So the question is, am I dreaming of a capability that does not exist ?

My applications are written in DEC Basic. I'd sort of hoped that I would not have to re-create the C header files definitions in Basic, nor work out how to call the SSL routines from a language other than C.

Sort of gets back to my original question. Does HP have and documentation specific to using SSL in VMS ??

[Richard Brodie_1]

The SSL documentation is in the base VMS documentation set:
http://h71000.www7.hp.com/doc/83FINAL/BA554_90007/index.html

"I was sort of hoping that SSL was used by TCP/IP, such that I'd set a flag on a socket, and TCP/IP would transparently do the SSL stuff. So the question is, am I dreaming of a capability that does not exist ? "

That would be closer to IPsec, rather than SSL.

[Richard Whalen]

When using SSL you generally replace your calls to TCP/IP routines with calls to SSL routines. The SSL routines will then use either built in or your own routines to write the encrypted data over the TCP/IP connection.

[David Froble]

Ok, found the documentation. Thanks Richard. For some reason my searches ended up with 8.2 documentation, not 8.3 documentation.

It's becoming apparent to me that this is not going to be a "plug in SSL and use it" thing. Would somebody pass the bottle of aspirin please.

Some more questions:

When an incoming connection request, from a client wishing a secure connection, it seems to me that that connection request itself cannot be secure, since the SSL handshake has not yet occurred. What is there in a connection request that asks for a secure connection ?

Or should the listener be handling this logic ?

Is there any information, anywhere, of using SSL on VMS from any language other than C ?

Data structure definitions ?

[Richard Whalen]

If having a secure connection is optional, then it is necessary for the client and server to come to an agreement on this before they call the SSL_do_handshake routine. One model you could look at is RFC 4217 (Securing FTP with TLS). http://www.ietf.org/rfc/rfc4217.txt?number=4217 Specifically the AUTH TLS command.

(Open)SSL comes to us from the Unix world, where C is the primary language. You may end up having to create a couple of C modules that handle the interface between your program and SSL. This could also help keep the overall code easier to read as it would hide most of the mechanics of SSL.

[Hoff]

If the data rates and the environment permits it, migrating the existing IP connections over to an outboard VPN device might be a reasonable alternative. Minimal (or no) changes to the host code would be required.

[Richard J Maher]

Hi David,

I see no one has yet mentioned "Stunnel" (versions of which are available for VMS). Basically it sit's on port X and does the SSL and then redirects the messages to your non-SSL port Y. DoS attacks being a bit problematic :-( It also doesn't support OOB data but I'm sure I've seen and SSL RFC somewhere that says OOB data is included in the standard?

You may also wish to look at Process Software's IPsec which has been available for some years now. As long as you have fixed IP addresses then I don't see a problem with it. UCX has also been promising to come out with a version of IPsec for as long as I can remember but to-date have only come out with a "Early Adopters Kit" whose very name has left the more cautious in the user-base a tad unwilling to embrace it.

IPsec is the future! (As soon as the usual System/Network management inertia is overcome :-)

No more SFTP/FTPs, SSH, 80/443. . .

Cheers Richard Maher

[Robert Gezelter]

David,

In a word, as has been noted, SSL (and most of the IP stack) do not work that way. As an example, consider HTTP (TCP port 80) and HTTPS (TCP port 443).

OpenVMS BASIC does have all of the abilities to generate the interfaces, albeit it can be cumbersome at times. The C interface conventions are no more conceptually difficult than calling OpenVMS system services from BASIC. However, as the bindings are not maintained for BASIC, it will be easier to maintain the C code.

- Bob Gezelter, http://www.rlgsc.com

[David Froble]

Richard

Thanks for the info. To be truthful, I know that I'm unfamiliar with the concepts, and may have some misconceptions. But it seems to me that none of the options are seamless. No real standards, unless you make some assumptions, such as "both sides will assume SSL V3" or something like that.

I'm not very familiar with IPsec, but from the small exposure, it also seems to need some up front set-up.

My environment is, possibly thousands of small businesses with a PC connecting, and placing orders, which will include credit card information. Thus security is required. However, it needs to be rather seemless, because doing up front set-up with all the small businesses would be very labor intensive, and would probably fail.

The application has pretty much cornered the small power equipment distribution verticle market, and for you VMS bigots, it's mainly a VMS based application, written mainly in DEC Basic, with a database developed originally on RSTS/E and used for many years.

So you have every little mom and pop shop out there that repairs lawn mowers and such placing orders, and most are not what you'd consider "computer literate".

What I "think" I need is the transparent manner in which browsers and web servers use to negotiate secure connections, without the user knowing anything about the mechanics.

I don't know if this will work with IPsec. Will it ??

---------------------

Robert

I have to believe that with VMS any language can use routines written in any other language supported by VMS. Though C does seem (to me) to be a bit less 'standard' than anything else.

Probably the major problem is that I don't know C, and frankly don't want to know C. If required data structures were defined in a manner that DEC documentation used to use, specifying VMS data types, I think I could figure things out. However, current documentation practices seem to be publish some C code rather than generic examples.

I'm going to try to understand the SSL Structure in ssl.h, but fear that without some help, it's going to be a long and hard job. If I can define static data structures that appear to be required in any program using the SSL library, then I think I can get things working.

I'm working on getting paper manual, as I don't do well with online documentation.

[Robert Gezelter]

David,

What about using WASD or Apache to do the heavy lifting on the SSL connection. If the connection is done using HTTPS, then the web server will handle the SSL connections automagically.

The processing of the credit card information can then be done in a script called from the web server.

- Bob Gezelter, http://www.rlgsc.com

[Richard J Maher]

Hi David,

Look, the last thing anyone wants to do is frustrate the customer from buying your wares! If run-time discovery of customers is a business requirement for you, then IPsec is probably not the easiest fit. Why not stick to some http(s) server with bollocks script and cookies and quasi-session expiration, and hijacking, and so on. . .

Maybe you don't have any form of account information to be verified on the server side (password perhaps?) Maybe you don't bother matching the delivery address to the CC billing address - I don't know. HTTPS is probably best for you, or do look at "Stunnel" as a soft option (or *yes* use the HP supported OpenSSL routines in C)

On the other hand, if you were involved in a branch-office to head-office scenario, or your customers had to register an account with you before trading and you kept things like purchase/credit history and contact information, and security was important to you, then the one-off effort in configuring IPsec may not be too much of a hardship? You may even like to authenticate client instead of just satisfy their server authentication. (Does it matter if you're talking to who you think you are?)

Cheers Richard Maher

PS. Unlike HP/VMS/UCX Microsoft has supported IPsec for many years - it's not rocket science!