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 subdirectories numbered 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 connection.
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 ALSO
listen(8),
dial(2)
SOURCE
/sys/src/9/port/devssl.c
BUGS
Messages longer than 4096 bytes are truncated.