[Info-vax] Once again trying to use the SSL ported to VMS

[David Froble]

Being true to myself, there's always got to be a bit of a rant
involved.  :-)

It's my observation that the OpenSSL port to VMS is actually a port to
C on VMS.  There is no documentation in "VMS" terms, at least similar
to what DEC produced in the past, and examples are in C.  Ok, got that
over with.

I'm once more trying to use SSL with programs written in Basic.  The
problems I'm having seem to be that much is "hidden" in the multitude
of ".h" files that seem to be included in every C program.  That, and
the problem of the C parameter passing not conforming to much of
anything else on VMS.  Not ranting, just explaining.

I'm using SYS$COMMON:[SYSHLP.EXAMPLES.SSL]SSL$TCP_SERVER_QIO_SSL.C
(usually SSL$EXAMPLES is a logical for the location) as a guide in my
attempt to use SSL.  Actually, much of the program is similar to the
Basic programs I've been using for socket communications.

What I've been able to guess at is that the SSL routines for the most
part use structures to store the information for subsequent calls to
the SSL routines, and that the calling program has only longwords
(pointers) to the structures.  I can only hope that the structures
persist after a SSL routine exits.  I'm guessing that the sharable
RTLs (using 32 bit RTLs) provide for this as a local copy.  This is
one thing that I've never used in the past, so I'm just guessing.

While I still have some things to work on, such as setting up some
certificates properly, I think I may actually be close to getting this
to work.  There are some specifics in the example program mentioned
above where I do not have a clue as to what is intended.  I'm hoping
someone somewhere can enlighten me.

   /* Create a SSL_METHOD structure (choose a SSL/TLS protocol
version) */
   meth = SSLv3_method();

   /* Create a SSL_CTX structure */
   ctx = SSL_CTX_new(meth);
   RETURN_NULL(ctx);

In the above, I've assumed that meth is a pointer to some internal
data, thus I can just use a longword to store the pointer, and I can
then pass it "By Value".  This seems to be working.  However, I could
not find much about what "RETURN_NULL()" is, though I can guess it is
initializing a new structure to NULL.  The symbol does not resolve in
the linker.  The only place I've found it is in another example
program.

#define RETURN_NULL(x) if ((x)==NULL) exit(1)

I've got the program to al least run by commenting out the command.  I
doubt that is a satisfactory solution.

Another section of code where I haven't a clue:

    **  Assign the socket into the SSL structure
    **  (SSL and socket without BIO)
    */

    sock = decc$socket_fd ( conn_channel );

    err = SSL_set_fd( ssl , sock );
    if ( err == -1 )
        check_error( ssl , err , \
        "- ERROR - during SERVER assigning socket to SSL object");

I assume decc$socket_fd() is a DEC C routine, and I assume that the
channel is being passed to it By Value.  I don't know what it's doing,
and I don't know what type of data it returns.  I can "hope" that
"sock" is a pointer, to be stored in a longword.

Then I'm assuming that the SSL routine SSL_set_fd() is somehow
associating the socket so that SSL_read() and SSL_write() will perform
I/O on the socket.

Some idea of the data type of "sock" and the operation of decc
$socket_fd() would be helpful.

Back to ranting.  DEC used to specify what routines did, and the
parameter types and passing mechanisms in their documentation.  I
guess such ideas are foreign to Unix, and therefore to any ports of
Unix software.  I would expect that any reasonable port would have
documented all of the SSL* routines, their parameters, their
operation, and their return data, as a minimum requirement.  Guess
not.  Then again, I spent most of my life in another century.  I guess
times change.