1 .\" $OpenBSD: SSL_read.3,v 1.4 2016/12/07 18:47:23 schwarze Exp $
2 .\" OpenSSL 99d63d46 Oct 26 13:56:48 2016 -0400
4 .\" This file was written by Lutz Jaenicke <jaenicke@openssl.org> and
5 .\" Matt Caswell <matt@openssl.org>.
6 .\" Copyright (c) 2000, 2001, 2008, 2016 The OpenSSL Project. All rights reserved.
8 .\" Redistribution and use in source and binary forms, with or without
9 .\" modification, are permitted provided that the following conditions
12 .\" 1. Redistributions of source code must retain the above copyright
13 .\" notice, this list of conditions and the following disclaimer.
15 .\" 2. Redistributions in binary form must reproduce the above copyright
16 .\" notice, this list of conditions and the following disclaimer in
17 .\" the documentation and/or other materials provided with the
20 .\" 3. All advertising materials mentioning features or use of this
21 .\" software must display the following acknowledgment:
22 .\" "This product includes software developed by the OpenSSL Project
23 .\" for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
25 .\" 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
26 .\" endorse or promote products derived from this software without
27 .\" prior written permission. For written permission, please contact
28 .\" openssl-core@openssl.org.
30 .\" 5. Products derived from this software may not be called "OpenSSL"
31 .\" nor may "OpenSSL" appear in their names without prior written
32 .\" permission of the OpenSSL Project.
34 .\" 6. Redistributions of any form whatsoever must retain the following
36 .\" "This product includes software developed by the OpenSSL Project
37 .\" for use in the OpenSSL Toolkit (http://www.openssl.org/)"
39 .\" THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
40 .\" EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
41 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
42 .\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR
43 .\" ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
44 .\" SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
45 .\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
46 .\" LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
47 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
48 .\" STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
49 .\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
50 .\" OF THE POSSIBILITY OF SUCH DAMAGE.
52 .Dd $Mdocdate: December 7 2016 $
58 .Nd read bytes from a TLS/SSL connection
62 .Fn SSL_read "SSL *ssl" "void *buf" "int num"
64 .Fn SSL_peek "SSL *ssl" "void *buf" "int num"
69 bytes from the specified
77 except that no bytes are removed from the underlying BIO during
78 the read, such that a subsequent call to
80 will yield at least the same bytes once again.
89 If necessary, a read function will negotiate a TLS/SSL session, if
90 not already explicitly performed by
94 If the peer requests a re-negotiation, it will be performed
95 transparently during the read function operation.
96 The behaviour of the read functions depends on the underlying
99 For the transparent negotiation to succeed, the
101 must have been initialized to client or server mode.
102 This is done by calling
103 .Xr SSL_set_connect_state 3
105 .Xr SSL_set_accept_state 3
106 before the first call to a read function.
108 The read functions works based on the SSL/TLS records.
109 The data are received in records (with a maximum record size of 16kB).
110 Only when a record has been completely received, it can be processed
111 (decrypted and checked for integrity).
112 Therefore data that was not retrieved at the last read call can
113 still be buffered inside the SSL layer and will be retrieved on the
117 is higher than the number of bytes buffered, the read functions
118 will return with the bytes buffered.
119 If no more bytes are in the buffer, the read functions will trigger
120 the processing of the next record.
121 Only when the record has been received and processed completely
122 will the read functions return reporting success.
123 At most the contents of the record will be returned.
124 As the size of an SSL/TLS record may exceed the maximum packet size
125 of the underlying transport (e.g., TCP), it may be necessary to
126 read several packets from the transport layer before the record is
127 complete and the read call can succeed.
132 a read function will only return once the read operation has been
133 finished or an error occurred, except when a renegotiation takes
134 place, in which case an
135 .Dv SSL_ERROR_WANT_READ
137 This behavior can be controlled with the
138 .Dv SSL_MODE_AUTO_RETRY
140 .Xr SSL_CTX_set_mode 3
145 is non-blocking, a read function will also return when the underlying
147 could not satisfy the needs of the function to continue the operation.
148 In this case a call to
150 with the return value of the read function will yield
151 .Dv SSL_ERROR_WANT_READ
153 .Dv SSL_ERROR_WANT_WRITE .
154 As at any time a re-negotiation is possible, a read function may
155 also cause write operations.
156 The calling process must then repeat the call after taking appropriate
157 action to satisfy the needs of the read function.
158 The action depends on the underlying
160 When using a non-blocking socket, nothing is to be done, but
162 can be used to check for the required condition.
163 When using a buffering
167 pair, data must be written into or retrieved out of the
169 before being able to continue.
172 can be used to find out whether there are buffered bytes available for
174 In this case a read function can be called without blocking or
175 actually receiving new data from the underlying socket.
177 When a read function operation has to be repeated because of
178 .Dv SSL_ERROR_WANT_READ
180 .Dv SSL_ERROR_WANT_WRITE ,
181 it must be repeated with the same arguments.
183 The following return values can occur:
186 The read operation was successful.
187 The return value is the number of bytes actually read from the
190 The read operation was not successful.
191 The reason may either be a clean shutdown due to a
193 alert sent by the peer (in which case the
194 .Dv SSL_RECEIVED_SHUTDOWN
195 flag in the ssl shutdown state is set (see
198 .Xr SSL_set_shutdown 3 ) .
199 It is also possible that the peer simply shut down the underlying transport and
200 the shutdown is incomplete.
203 with the return value to find out whether an error occurred or the connection
204 was shut down cleanly
205 .Pq Dv SSL_ERROR_ZERO_RETURN .
207 The read operation was not successful, because either an error occurred or
208 action must be taken by the calling process.
211 with the return value to find out the reason.
219 .Xr SSL_CTX_set_mode 3 ,
220 .Xr SSL_get_error 3 ,
222 .Xr SSL_set_connect_state 3 ,
223 .Xr SSL_set_shutdown 3 ,