3 tls \- TLS1 and SSL3 record layer
15 .BI /net/tls/ n /stats
16 .BI /net/tls/ n /status
19 The TLS device implements the record layer protocols
20 of Transport Layer Security version 1.0 and Secure Sockets Layer version 3.0.
21 It does not implement the handshake protocols, which are responsible for
22 mutual authentication and key exchange.
25 device can be thought of as filters providing optional encryption and anti-tampering.
27 The top level directory contains a
29 file and subdirectories numbered from zero through at least the last active filter.
32 file reserves a filter.
33 The file descriptor returned from the
35 will point to the control file,
37 of the newly allocated filter.
40 file returns a text string containing the number of the filter directory.
42 The filter initially cannot be used to pass messages
43 and will not encrypt or digest messages.
44 It is configured and controlled by writing commands to
47 The following commands are supported:
49 .BI fd \ open-fd\ vers
50 Pass record messages over the communications channel
52 Initially, outgoing messages use version
54 format records, but incoming messages of either version are accepted.
59 for TLSv1.0 (which could be known as SSLv3.01.)
60 This command must be issued before any other command
61 and before reading or writing any messages;
62 it may only be executed once.
67 format records for all future records,
68 both outgoing and incoming.
69 This command may only be executed once.
71 .BI secret \ hashalg\ encalg\ isclient\ secretdata
72 Set up the digesting and encryption algorithms and secrets.
76 must be algorithm names returned by the corresponding files.
78 is the base-64 encoded (see
80 secret data used for the algorithms.
81 It must contain at least enough data to populate the
82 secrets for digesting and encrypting.
83 These secrets are divided into three categories: digest secrets, keys, and initialization vectors.
84 The secrets are packed in this order, with no extra padding.
85 Within each category, the secret for data traveling from the client to the server comes first.
86 The incoming and outgoing secrets are automatically selected by devtls based on the
88 argument, which must be non-zero for the client of the TLS handshake,
89 and zero for the server.
91 This command must be issued after
93 and may be issued more than once.
96 command must be issued before each
98 command; similarly, at least one new
100 must precede each incoming changecipher message.
103 Enable outgoing encryption and digesting as configured by the previous
111 Enable data messages.
112 This command may be issued any number of times,
113 although only the first is significant.
114 It must follow at least one successful
119 Send an alert message.
121 may be a valid alert code for either SSLv3.0 or TLSv1.0,
122 and is mapped to an appropriate code for the protocol in use.
123 If it is a fatal alert, the filter is set into an error state.
125 Application messages and handshake messages are communicated using
134 is allowed at a time.
136 Any record layer headers and trailers are inserted and
137 stripped automatically, and are not visible from the outside.
138 The device tries to synchronize record boundaries with reads and writes.
139 Each read will return data from exactly one record,
140 and will return all of the data from the record as long as
141 the buffer is big enough.
142 Each write will be converted into an integral number of records,
143 with all but potentially the last being maximal size.
144 The maximum record length supported is 16384 bytes.
145 This behavior is not specified in the protocols,
146 and may not be followed by other implementations.
148 If a fatal alert message is received, or a fatal
150 command issued, the filter is set into an error state.
151 All further correspondence is halted,
152 although some pending operations may not be terminated.
159 will fail with a textual decoding of the alert.
160 The current non-fatal alert messages are
161 .BR "'close notify'" ,
162 .BR "'no renegotiation'" ,
164 .BR "'handshake canceled by user'" .
165 Receipt of one of these alerts cause the next read on
167 to terminate with an error.
169 .BR "'close notify'",
170 all future reads will terminate with a
176 command will terminate all future writes or reads from
182 If an error is encountered while reading or writing
183 the underlying communications channel, the error is returned
184 to the offending operation.
186 .BR "'interrupted'" ,
187 the filter is set into the error state.
188 In this case, all future operations on
191 .BR "'channel error'" .
193 When all file descriptors for a filter have been closed,
194 the session is terminated and the filter reclaimed for future use.
197 alert will be sent on the underlying communications channel
198 unless one has already been sent or the filter is in the error state.
204 returns information about the filter.
205 Each datum is returned on a single line of the form
208 returns the number of bytes communicated by the
213 The four lines returned are tagged by, in order,
220 returns lines following tags:
233 value is a string describing the status of the connection,
234 and is one of the following:
244 give the hexadecimal record layer version in use.
249 fields return name of the current algorithms in use
250 or ready to be used, if any.
256 will give the space-separated list of algorithms implemented.
257 This will always include
259 meaning no encryption or digesting.
260 Currently implemented encryption algorithms are
266 Currently implemented hashing algorithms are
275 .B /sys/src/9/port/devtls.c
projects / plan9front.git / blob