glenda.party
term% ls -F
term% pwd
$home/manuals/9front/3/ssl
term% cat index.txt
SSL(3)                     Library Functions Manual                     SSL(3)



NAME
       ssl - SSL record layer

SYNOPSIS
       bind -a #D /net

       /net/ssl/clone
       /net/ssl/n
       /net/ssl/n/ctl
       /net/ssl/n/data
       /net/ssl/n/encalgs
       /net/ssl/n/hashalgs
       /net/ssl/n/secretin
       /net/ssl/n/secretout

DESCRIPTION
       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 ex‐
       change.)  The ssl device can be thought of as a  filter  providing  op‐
       tional encryption and anti-tampering.

       The  top  level directory contains a clone file and subdirectories num‐
       bered from zero to the number of connections configured.   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.   Reading  the  ctl file returns a text string representing
       the number of the connection.

       A connection is controlled by writing text strings  to  the  associated
       ctl  file.   After  a  connection has been established 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 correspond to one read.

       Options are set by writing control messages to the ctl file of the con‐
       nection.

       The following control messages are supported:

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

       alg cryptoalgs
              Connections start in alg clear which means no encryption or  di‐
              gesting.  Writing alg sha to the control file turns on SHA-1 di‐
              gest authentication for the data  channel.   Similarly,  writing
              alg  rc4_128  enables encryption.  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 be‐
              low.

       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 se‐
       cretout.  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.

SEE ALSO
       listen(8), dial(2)

SOURCE
       /sys/src/9/port/devssl.c

BUGS
       Messages longer than 4096 bytes are truncated.



                                                                        SSL(3)