SSL(3)SSL(3)NAMEssl - 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 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
digesting. Writing alg sha to the control file turns on SHA-1
digest 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
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 ALSOlisten(8), dial(2)SOURCE
/sys/src/9/port/devssl.c
BUGS
Messages longer than 4096 bytes are truncated.
SSL(3)
