SSL(3) 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 exchange.) The ssl device can
be thought of as a filter providing optional encryption and
anti-tampering.
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 11/21/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.
SEE ALSO
listen(8), dial(2)
SOURCE
/sys/src/9/port/devssl.c
BUGS
Messages longer than 4096 bytes are truncated.
Page 2 Plan 9 (printed 11/21/24)