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)