SSL(3)                                                     SSL(3)

          ssl - SSL record layer

          bind -a #D /net


          The SSL device provides the interface to the Secure Socket
          Layer device implementing the record layer protocol of SSLv2
          (but not the handshake protocol, which is responsible for
          mutual authentication and key exchange.)  The ssl device can
          be thought of as a filter providing optional encryption and

          The top level directory contains a clone file and subdirec-
          tories numbered from zero to the number of connections con-
          figured.  Opening the clone file reserves a connection.  The
          file descriptor returned from the open(2) will point to the
          control file, ctl, of the newly allocated connection.  Read-
          ing the ctl file returns a text string representing the num-
          ber of the connection.

          A connection is controlled by writing text strings to the
          associated ctl file.  After a connection has been estab-
          lished data may be read from and written to the data file.

          The SSL protocol provides a stream connection that preserves
          read/write boundaries.  As long as reads always specify
          buffers that are of equal or greater lengths than the writes
          at the other end of the connection, one write will corre-
          spond to one read.

          Options are set by writing control messages to the ctl file
          of the connection.

          The following control messages are supported:

          fd open-file-descriptor
               Run the SSL protocol over the existing file descriptor.

          alg cryptoalgs

     Page 1                       Plan 9             (printed 7/23/24)

     SSL(3)                                                     SSL(3)

               Connections start in alg clear which means no encryp-
               tion or digesting.  Writing alg sha to the control file
               turns on SHA-1 digest authentication for the data chan-
               nel.  Similarly, writing alg rc4_128 enables encryp-
               tion.  Both can be turned on at once by alg sha
               rc4_128.  The digest mode sha may be replaced by md5.
               The encryption mode rc4_128 may be replaced by rc4_40,
               rc4_128, rc4_256, des_40_ecb, des_40_cbc, des_56_ecb,
               and des_56_cbc.  The mode may be changed at any time
               during the connection.

          secretin base64-secret
               The secret for decrypting and authenticating incoming
               messages can be specified either as a base64 encoded
               string by writing to the control file, or as a binary
               byte string using the interface below.

          secretout base64-secret
               The secret for encrypting and hashing outgoing messages
               can be specified either as a base64 encoded string by
               writing to the control file, or as a binary byte string
               using the interface below.

          Before enabling digesting or encryption, shared secrets must
          be agreed upon with the remote side, one for each direction
          of transmission, and loaded as shown above or by writing to
          the files secretin and secretout. If either the incoming or
          outgoing secret is not specified, the other secret is
          assumed to work for both directions.

          The encryption and hash algoritms actually included in the
          kernel may be smaller than the set presented here.  Reading
          encalgs and hashalgs will give the actual space-separated
          list of algorithms implemented.

          listen(8), dial(2)


          Messages longer than 4096 bytes are truncated.

     Page 2                       Plan 9             (printed 7/23/24)