1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
|
.\"
.\" $OpenBSD: SSL_read.3,v 1.2 2014/12/02 14:11:01 jmc Exp $
.\"
.Dd $Mdocdate: December 2 2014 $
.Dt SSL_READ 3
.Os
.Sh NAME
.Nm SSL_read
.Nd read bytes from a TLS/SSL connection
.Sh SYNOPSIS
.In openssl/ssl.h
.Ft int
.Fn SSL_read "SSL *ssl" "void *buf" "int num"
.Sh DESCRIPTION
.Fn SSL_read
tries to read
.Fa num
bytes from the specified
.Fa ssl
into the buffer
.Fa buf .
.Sh NOTES
If necessary,
.Fn SSL_read
will negotiate a TLS/SSL session, if not already explicitly performed by
.Xr SSL_connect 3
or
.Xr SSL_accept 3 .
If the peer requests a re-negotiation,
it will be performed transparently during the
.Fn SSL_read
operation.
The behaviour of
.Fn SSL_read
depends on the underlying
.Vt BIO .
.Pp
For the transparent negotiation to succeed, the
.Fa ssl
must have been initialized to client or server mode.
This is being done by calling
.Xr SSL_set_connect_state 3
or
.Xr SSL_set_accept_state 3
before the first call to
.Fn SSL_read
or
.Xr SSL_write 3 .
.Pp
.Fn SSL_read
works based on the SSL/TLS records.
The data are received in records (with a maximum record size of 16kB for
SSLv3/TLSv1).
Only after a record has been completely received can it be processed
(decrypted and checked for integrity).
Therefore data not retrieved at the last call of
.Fn SSL_read
can still be buffered inside the SSL layer and will be retrieved on the next
call to
.Fn SSL_read .
If
.Fa num
is higher than the number of bytes buffered,
.Fn SSL_read
will return with the bytes buffered.
If no more bytes are in the buffer,
.Fn SSL_read
will trigger the processing of the next record.
Only when the record has been received and processed completely will
.Fn SSL_read
return reporting success.
At most the contents of the record will be returned.
As the size of an SSL/TLS record may exceed the maximum packet size of the
underlying transport (e.g., TCP), it may be necessary to read several packets
from the transport layer before the record is complete and
.Fn SSL_read
can succeed.
.Pp
If the underlying
.Vt BIO
is
.Em blocking ,
.Fn SSL_read
will only return once the read operation has been finished or an error
has occurred, except when a renegotiation take place, in which case a
.Dv SSL_ERROR_WANT_READ
may occur.
This behavior can be controlled with the
.Dv SSL_MODE_AUTO_RETRY
flag of the
.Xr SSL_CTX_set_mode 3
call.
.Pp
If the underlying
.Vt BIO
is
.Em non-blocking ,
.Fn SSL_read
will also return when the underlying
.Vt BIO
could not satisfy the needs of
.Fn SSL_read
to continue the operation.
In this case a call to
.Xr SSL_get_error 3
with the return value of
.Fn SSL_read
will yield
.Dv SSL_ERROR_WANT_READ
or
.Dv SSL_ERROR_WANT_WRITE .
As at any time a re-negotiation is possible, a call to
.Fn SSL_read
can also cause write operations!
The calling process then must repeat the call after taking appropriate action
to satisfy the needs of
.Fn SSL_read .
The action depends on the underlying
.Vt BIO .
When using a non-blocking socket, nothing is to be done, but
.Xr select 2
can be used to check for the required condition.
When using a buffering
.Vt BIO ,
like a
.Vt BIO
pair, data must be written into or retrieved out of the
.Vt BIO
before being able to continue.
.Pp
.Xr SSL_pending 3
can be used to find out whether there are buffered bytes available for
immediate retrieval.
In this case
.Fn SSL_read
can be called without blocking or actually receiving new data from the
underlying socket.
.Sh WARNING
When an
.Fn SSL_read
operation has to be repeated because of
.Dv SSL_ERROR_WANT_READ
or
.Dv SSL_ERROR_WANT_WRITE ,
it must be repeated with the same arguments.
.Sh RETURN VALUES
The following return values can occur:
.Bl -tag -width Ds
.It >0
The read operation was successful; the return value is the number of bytes
actually read from the TLS/SSL connection.
.It 0
The read operation was not successful.
The reason may either be a clean shutdown due to a
.Dq close notify
alert sent by the peer (in which case the
.Dv SSL_RECEIVED_SHUTDOWN
flag in the ssl shutdown state is set (see
.Xr SSL_shutdown 3
and
.Xr SSL_set_shutdown 3 ) .
It is also possible that the peer simply shut down the underlying transport and
the shutdown is incomplete.
Call
.Fn SSL_get_error
with the return value to find out whether an error occurred or the connection
was shut down cleanly
.Pq Dv SSL_ERROR_ZERO_RETURN .
.Pp
SSLv2 (deprecated) does not support a shutdown alert protocol, so it can only
be detected whether the underlying connection was closed.
It cannot be checked whether the closure was initiated by the peer or by
something else.
.It <0
The read operation was not successful, because either an error occurred or
action must be taken by the calling process.
Call
.Fn SSL_get_error
with the return value to find out the reason.
.El
.Sh SEE ALSO
.Xr bio 3 ,
.Xr ssl 3 ,
.Xr SSL_accept 3 ,
.Xr SSL_connect 3 ,
.Xr SSL_CTX_new 3 ,
.Xr SSL_CTX_set_mode 3 ,
.Xr SSL_get_error 3 ,
.Xr SSL_pending 3 ,
.Xr SSL_set_connect_state 3 ,
.Xr SSL_set_shutdown 3 ,
.Xr SSL_shutdown 3 ,
.Xr SSL_write 3
|
