tls – TLS1 and SSL3 record layer|
bind –a #a /net |
The TLS device implements the record layer protocols of Transport
Layer Security version 1.0 and Secure Sockets Layer version 3.0.
It does not implement the handshake protocols, which are responsible
for mutual authentication and key exchange. The tls device can
be thought of as filters providing optional
encryption and anti–tampering. |
The top level directory contains a clone file and subdirectories numbered from zero through at least the last active filter. Opening the clone file reserves a filter. The file descriptor returned from the open(2) will point to the control file, ctl, of the newly allocated filter. Reading the ctl file returns a text string containing the number of the filter directory.
The filter initially cannot be used to pass messages and will not encrypt or digest messages. It is configured and controlled by writing commands to ctl.
The following commands are supported:
Any record layer headers and trailers are inserted and stripped automatically, and are not visible from the outside. The device tries to synchronize record boundaries with reads and writes. Each read will return data from exactly one record, and will return all of the data from the record as long as the buffer is big enough. Each write will be converted into an integral number of records, with all but potentially the last being maximal size. The maximum record length supported is 16384 bytes. This behavior is not specified in the protocols, and may not be followed by other implementations.
If a fatal alert message is received, or a fatal alert command issued, the filter is set into an error state. All further correspondence is halted, although some pending operations may not be terminated. Operations on data will fail with a 'tls error', and operations on hand will fail with a textual decoding of the alert. The current non–fatal alert messages are 'close notify', 'no renegotiation', and 'handshake canceled by user' (sic). Receipt of one of these alerts cause the next read on hand to terminate with an error. If the alert is 'close notify', all future reads will terminate with a tls hungup error. A 'close notify' alert command will terminate all future writes or reads from data with a 'tls hungup' error.
If an error is encountered while reading or writing the underlying communications channel, the error is returned to the offending operation. If the error is not 'interrupted', the filter is set into the error state. In this case, all future operations on hand will fail with a 'channel error'.
When all file descriptors for a filter have been closed, the session is terminated and the filter reclaimed for future use. A 'close notify' alert will be sent on the underlying communications channel unless one has already been sent or the filter is in the error state.
Reading stats or status returns information about the filter. Each datum is returned on a single line of the form tag: data. Stats returns the number of bytes communicated by the data and hand channels. The four lines returned are tagged by, in order, DataIn, DataOut, HandIn, and HandOut. Status returns lines following tags: State, Version, EncIn, HashIn, NewEncIn, NewHashIn, EncOut, HashOut, NewEncOut, and NewHashOut. State's value is a string describing the status of the connection, and is one of the following: 'Handshaking', 'Established', 'RemoteClosed', 'LocalClosed', 'Alerting', 'Errored', or 'Closed'. Version's give the hexadecimal record layer version in use. The Enc and Hash fields return name of the current algorithms in use or ready to be used, if any.
Reading encalgs and hashalgs will give the space–separated list
of algorithms implemented. This will always include clear, meaning
no encryption or digesting. Currently implemented encryption algorithms
are 'rc4_128', '3des_ede_cbc', 'aes_128_cbc' and 'aes_256_cbc'.
hashing algorithms are 'md5' and 'sha1'.
listen(8), dial(2), pushtls(2)|