diff options
author | schwarze <> | 2016-11-21 13:52:28 +0000 |
---|---|---|
committer | schwarze <> | 2016-11-21 13:52:28 +0000 |
commit | 0d01f90c1335701056a00536c40e6975abd289d3 (patch) | |
tree | 6cdfd99704342bdbc29674493e824f72459a40ad /src | |
parent | e4eb752ba6b091f0c025576c3f8d396bd0f294aa (diff) | |
download | openbsd-0d01f90c1335701056a00536c40e6975abd289d3.tar.gz openbsd-0d01f90c1335701056a00536c40e6975abd289d3.tar.bz2 openbsd-0d01f90c1335701056a00536c40e6975abd289d3.zip |
Import the DTLSv1_listen(3) manual from OpenSSL,
excluding interface changes that don't apply to LibreSSL,
except that i left the confusing discussion of RETURN VALUES
completely unchanged, to warn users that this is a mess:
OpenSSL first published this interface, then later changed
its syntax and semantics in multiple ways.
Diffstat (limited to 'src')
-rw-r--r-- | src/lib/libssl/man/DTLSv1_listen.3 | 186 | ||||
-rw-r--r-- | src/lib/libssl/man/Makefile | 3 |
2 files changed, 188 insertions, 1 deletions
diff --git a/src/lib/libssl/man/DTLSv1_listen.3 b/src/lib/libssl/man/DTLSv1_listen.3 new file mode 100644 index 0000000000..9ecd5589b3 --- /dev/null +++ b/src/lib/libssl/man/DTLSv1_listen.3 | |||
@@ -0,0 +1,186 @@ | |||
1 | .\" $OpenBSD: DTLSv1_listen.3,v 1.1 2016/11/21 13:52:28 schwarze Exp $ | ||
2 | .\" OpenSSL 7795475f Dec 18 13:18:31 2015 -0500 | ||
3 | .\" | ||
4 | .\" This file was written by Matt Caswell <matt@openssl.org>. | ||
5 | .\" Copyright (c) 2015 The OpenSSL Project. All rights reserved. | ||
6 | .\" | ||
7 | .\" Redistribution and use in source and binary forms, with or without | ||
8 | .\" modification, are permitted provided that the following conditions | ||
9 | .\" are met: | ||
10 | .\" | ||
11 | .\" 1. Redistributions of source code must retain the above copyright | ||
12 | .\" notice, this list of conditions and the following disclaimer. | ||
13 | .\" | ||
14 | .\" 2. Redistributions in binary form must reproduce the above copyright | ||
15 | .\" notice, this list of conditions and the following disclaimer in | ||
16 | .\" the documentation and/or other materials provided with the | ||
17 | .\" distribution. | ||
18 | .\" | ||
19 | .\" 3. All advertising materials mentioning features or use of this | ||
20 | .\" software must display the following acknowledgment: | ||
21 | .\" "This product includes software developed by the OpenSSL Project | ||
22 | .\" for use in the OpenSSL Toolkit. (http://www.openssl.org/)" | ||
23 | .\" | ||
24 | .\" 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to | ||
25 | .\" endorse or promote products derived from this software without | ||
26 | .\" prior written permission. For written permission, please contact | ||
27 | .\" openssl-core@openssl.org. | ||
28 | .\" | ||
29 | .\" 5. Products derived from this software may not be called "OpenSSL" | ||
30 | .\" nor may "OpenSSL" appear in their names without prior written | ||
31 | .\" permission of the OpenSSL Project. | ||
32 | .\" | ||
33 | .\" 6. Redistributions of any form whatsoever must retain the following | ||
34 | .\" acknowledgment: | ||
35 | .\" "This product includes software developed by the OpenSSL Project | ||
36 | .\" for use in the OpenSSL Toolkit (http://www.openssl.org/)" | ||
37 | .\" | ||
38 | .\" THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY | ||
39 | .\" EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE | ||
40 | .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR | ||
41 | .\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR | ||
42 | .\" ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, | ||
43 | .\" SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT | ||
44 | .\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; | ||
45 | .\" LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) | ||
46 | .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, | ||
47 | .\" STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) | ||
48 | .\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED | ||
49 | .\" OF THE POSSIBILITY OF SUCH DAMAGE. | ||
50 | .\" | ||
51 | .Dd $Mdocdate: November 21 2016 $ | ||
52 | .Dt DTLSV1_LISTEN 3 | ||
53 | .Os | ||
54 | .Sh NAME | ||
55 | .Nm DTLSv1_listen | ||
56 | .Nd listen for incoming DTLS connections | ||
57 | .Sh SYNOPSIS | ||
58 | .In openssl/ssl.h | ||
59 | .Ft int | ||
60 | .Fo DTLSv1_listen | ||
61 | .Fa "SSL *ssl" | ||
62 | .Fa "struct sockaddr *peer" | ||
63 | .Fc | ||
64 | .Sh DESCRIPTION | ||
65 | .Fn DTLSv1_listen | ||
66 | listens for new incoming DTLS connections. | ||
67 | If a ClientHello is received that does not contain a cookie, then | ||
68 | .Fn DTLSv1_listen | ||
69 | responds with a HelloVerifyRequest. | ||
70 | If a ClientHello is received with a cookie that is verified, then | ||
71 | control is returned to user code to enable the handshake to be | ||
72 | completed (for example by using | ||
73 | .Xr SSL_accept 3 ) . | ||
74 | .Pp | ||
75 | .Fn DTLSv1_listen | ||
76 | is currently implemented as a macro. | ||
77 | .Pp | ||
78 | Datagram based protocols can be susceptible to Denial of Service | ||
79 | attacks. | ||
80 | A DTLS attacker could, for example, submit a series of handshake | ||
81 | initiation requests that cause the server to allocate state (and | ||
82 | possibly perform cryptographic operations) thus consuming server | ||
83 | resources. | ||
84 | The attacker could also (with UDP) quite simply forge the source IP | ||
85 | address in such an attack. | ||
86 | .Pp | ||
87 | As a counter measure to that DTLS includes a stateless cookie mechanism. | ||
88 | The idea is that when a client attempts to connect to a server it sends | ||
89 | a ClientHello message. | ||
90 | The server responds with a HelloVerifyRequest which contains a unique | ||
91 | cookie. | ||
92 | The client then resends the ClientHello, but this time includes the | ||
93 | cookie in the message thus proving that the client is capable of | ||
94 | receiving messages sent to that address. | ||
95 | All of this can be done by the server without allocating any state, and | ||
96 | thus without consuming expensive resources. | ||
97 | .Pp | ||
98 | OpenSSL implements this capability via the | ||
99 | .Fn DTLSv1_listen | ||
100 | function. | ||
101 | The | ||
102 | .Fa ssl | ||
103 | parameter should be a newly allocated | ||
104 | .Vt SSL | ||
105 | object with its read and write BIOs set, in the same way as might | ||
106 | be done for a call to | ||
107 | .Xr SSL_accept 3 . | ||
108 | Typically the read BIO will be in an "unconnected" state and thus | ||
109 | capable of receiving messages from any peer. | ||
110 | .Pp | ||
111 | When a ClientHello is received that contains a cookie that has been | ||
112 | verified, then | ||
113 | .Fn DTLSv1_listen | ||
114 | will return with the | ||
115 | .Fa ssl | ||
116 | parameter updated into a state where the handshake can be continued by a | ||
117 | call to (for example) | ||
118 | .Xr SSL_accept 3 . | ||
119 | Additionally the | ||
120 | .Vt struct sockaddr | ||
121 | pointed to by | ||
122 | .Fa peer | ||
123 | will be filled in with details of the peer that sent the ClientHello. | ||
124 | It is the calling code's responsibility to ensure that the | ||
125 | .Fa peer | ||
126 | location is sufficiently large to accommodate the addressing scheme in use. | ||
127 | For example this might be done by allocating space for a | ||
128 | .Vt struct sockaddr_storage | ||
129 | and casting the pointer to it to a | ||
130 | .Vt struct sockaddr * | ||
131 | for the call to | ||
132 | .Fn DTLSv1_listen . | ||
133 | Typically user code is expected to "connect" the underlying socket | ||
134 | to the peer and continue the handshake in a connected state. | ||
135 | .Pp | ||
136 | Prior to calling | ||
137 | .Fn DTLSv1_listen | ||
138 | user code must ensure that cookie generation and verification callbacks | ||
139 | have been set up using | ||
140 | .Fn SSL_CTX_set_cookie_generate_cb | ||
141 | and | ||
142 | .Fn SSL_CTX_set_cookie_verify_cb | ||
143 | respectively. | ||
144 | .Pp | ||
145 | Since | ||
146 | .Fn DTLSv1_listen | ||
147 | operates entirely statelessly whilst processing incoming ClientHellos, | ||
148 | it is unable to process fragmented messages (since this would require | ||
149 | the allocation of state). | ||
150 | An implication of this is that | ||
151 | .Fn DTLSv1_listen | ||
152 | only supports ClientHellos that fit inside a single datagram. | ||
153 | .Sh RETURN VALUES | ||
154 | From OpenSSL 1.1.0 a return value of >= 1 indicates success. | ||
155 | In this instance the | ||
156 | .Fa peer | ||
157 | value will be filled in and the | ||
158 | .Fa ssl | ||
159 | object set up ready to continue the handshake. | ||
160 | .Pp | ||
161 | A return value of 0 indicates a non-fatal error. | ||
162 | This could (for example) be because of non-blocking IO, or some invalid | ||
163 | message having been received from a peer. | ||
164 | Errors may be placed on the OpenSSL error queue with further information | ||
165 | if appropriate. | ||
166 | Typically user code is expected to retry the call to | ||
167 | .Fn DTLSv1_listen | ||
168 | in the event of a non-fatal error. | ||
169 | Any old errors on the error queue will be cleared in the subsequent | ||
170 | call. | ||
171 | .Pp | ||
172 | A return value of <0 indicates a fatal error. | ||
173 | This could (for example) be because of a failure to allocate sufficient | ||
174 | memory for the operation. | ||
175 | .Pp | ||
176 | Prior to OpenSSL 1.1.0 fatal and non-fatal errors both produce return | ||
177 | codes <= 0 (in typical implementations user code treats all errors as | ||
178 | non-fatal), whilst return codes >0 indicate success. | ||
179 | .Sh SEE ALSO | ||
180 | .Xr BIO 3 , | ||
181 | .Xr ssl 3 , | ||
182 | .Xr SSL_accept 3 , | ||
183 | .Xr SSL_get_error 3 | ||
184 | .Sh HISTORY | ||
185 | .Fn DTLSv1_listen | ||
186 | was added in OpenSSL 0.9.8. | ||
diff --git a/src/lib/libssl/man/Makefile b/src/lib/libssl/man/Makefile index 76afab5718..f02d3da424 100644 --- a/src/lib/libssl/man/Makefile +++ b/src/lib/libssl/man/Makefile | |||
@@ -1,8 +1,9 @@ | |||
1 | # $OpenBSD: Makefile,v 1.36 2016/11/05 15:32:19 schwarze Exp $ | 1 | # $OpenBSD: Makefile,v 1.37 2016/11/21 13:52:28 schwarze Exp $ |
2 | 2 | ||
3 | .include <bsd.own.mk> | 3 | .include <bsd.own.mk> |
4 | 4 | ||
5 | MAN = BIO_f_ssl.3 \ | 5 | MAN = BIO_f_ssl.3 \ |
6 | DTLSv1_listen.3 \ | ||
6 | SSL_CIPHER_get_name.3 \ | 7 | SSL_CIPHER_get_name.3 \ |
7 | SSL_COMP_add_compression_method.3 \ | 8 | SSL_COMP_add_compression_method.3 \ |
8 | SSL_CTX_add_extra_chain_cert.3 \ | 9 | SSL_CTX_add_extra_chain_cert.3 \ |