]>
Commit | Line | Data |
---|---|---|
f89c2a99 HL |
1 | =pod |
2 | ||
3 | =head1 NAME | |
4 | ||
5 | openssl-quic - OpenSSL QUIC | |
6 | ||
7 | =head1 DESCRIPTION | |
8 | ||
9 | OpenSSL 3.2 and later features support for the QUIC transport protocol. | |
4b4e246c HL |
10 | Currently, only client connectivity is supported. This man page describes the |
11 | usage of QUIC client functionality for both existing and new applications. | |
f89c2a99 HL |
12 | |
13 | QUIC functionality uses the standard SSL API. A QUIC connection is represented | |
14 | by an SSL object in the same way that a TLS connection is. Only minimal changes | |
15 | are needed to existing applications making use of the libssl APIs to make use of | |
16 | QUIC client functionality. To make use of QUIC, use the SSL method | |
17 | L<OSSL_QUIC_client_method(3)> or L<OSSL_QUIC_client_thread_method(3)> with | |
18 | L<SSL_CTX_new(3)>. | |
19 | ||
4b4e246c HL |
20 | When a QUIC connection is created, by default, it operates in default stream |
21 | mode, which is intended to provide compatibility with existing non-QUIC | |
22 | application usage patterns. In this mode, the connection has a single | |
23 | stream associated with it. Calls to L<SSL_read(3)> and | |
24 | L<SSL_write(3)> on the QUIC connection SSL object read and write from that | |
25 | stream. Whether the stream is client-initiated or server-initiated from a QUIC | |
26 | perspective depends on whether L<SSL_read(3)> or L<SSL_write(3)> is called | |
27 | first. See the MODES OF OPERATION section for more information. | |
28 | ||
29 | The default stream mode is intended for compatibility with existing | |
30 | applications. New applications using QUIC are recommended to disable default | |
31 | stream mode and use the multi-stream API; see the MODES OF OPERATION section and | |
32 | the RECOMMENDATIONS FOR NEW APPLICATIONS section for more information. | |
f89c2a99 HL |
33 | |
34 | The remainder of this man page discusses, in order: | |
35 | ||
36 | =over 4 | |
37 | ||
38 | =item | |
39 | ||
4b4e246c HL |
40 | Default stream mode versus multi-stream mode; |
41 | ||
42 | =item | |
43 | ||
f89c2a99 HL |
44 | The changes to existing libssl APIs which are driven by QUIC-related implementation |
45 | requirements, which existing applications should bear in mind; | |
46 | ||
47 | =item | |
48 | ||
49 | Aspects which must be considered by existing applications when adopting QUIC, | |
50 | including potential changes which may be needed. | |
51 | ||
52 | =item | |
53 | ||
54 | Recommended usage approaches for new applications. | |
55 | ||
56 | =item | |
57 | ||
58 | New, QUIC-specific APIs. | |
59 | ||
60 | =back | |
61 | ||
4b4e246c HL |
62 | =head1 MODES OF OPERATION |
63 | ||
64 | =head2 Default Stream Mode | |
65 | ||
66 | A QUIC client connection can be used in either default stream mode or | |
67 | multi-stream mode. By default, a newly created QUIC connection SSL object uses | |
68 | default stream mode. | |
69 | ||
70 | In default stream mode, a stream is implicitly created and bound to the QUIC | |
71 | connection SSL object; L<SSL_read(3)> and L<SSL_write(3)> calls to the QUIC | |
72 | connection SSL object work by default and are mapped to that stream. | |
73 | ||
74 | When default stream mode is used, any API function which can be called on a QUIC | |
75 | stream SSL object can also be called on a QUIC connection SSL object, in which | |
76 | case it affects the default stream bound to the connection. | |
77 | ||
78 | The identity of a QUIC stream, including its stream ID, varies depending on | |
79 | whether a stream is client-initiated or server-initiated. In default stream | |
80 | mode, if a client application calls L<SSL_read(3)> first before any call to | |
81 | L<SSL_write(3)> on the connection, it is assumed that the application protocol | |
82 | is using a server-initiated stream, and the L<SSL_read(3)> call will not | |
83 | complete (either blocking, or failing appropriately if nonblocking mode is | |
84 | configured) until the server initiates a stream. Conversely, if the client | |
85 | application calls L<SSL_write(3)> before any call to L<SSL_read(3)> on the | |
86 | connection, it is assumed that a client-initiated stream is to be used | |
87 | and such a stream is created automatically. | |
88 | ||
89 | Default stream mode is intended to aid compatibility with legacy applications. | |
90 | New applications adopting QUIC should use multi-stream mode, described below, | |
91 | and avoid use of the default stream functionality. | |
92 | ||
93 | It is possible to use additional streams in default stream mode using | |
94 | L<SSL_new_stream(3)> and L<SSL_accept_stream(3)>; note that the default incoming | |
95 | stream policy will need to be changed using L<SSL_set_incoming_stream_policy(3)> | |
96 | in order to use L<SSL_accept_stream(3)> in this case. However, applications | |
97 | using additional streams are strongly recommended to use multi-stream mode | |
98 | instead. | |
99 | ||
a855ee85 MC |
100 | Calling L<SSL_new_stream(3)> or L<SSL_accept_stream(3)> before a default stream |
101 | has been associated with the QUIC connection SSL object will inhibit future | |
102 | creation of a default stream. | |
103 | ||
4b4e246c HL |
104 | =head2 Multi-Stream Mode |
105 | ||
106 | The recommended usage mode for new applications adopting QUIC is multi-stream | |
107 | mode, in which no default stream is attached to the QUIC connection SSL object | |
108 | and attempts to call L<SSL_read(3)> and L<SSL_write(3)> on the QUIC connection | |
109 | SSL object fail. Instead, an application calls L<SSL_new_stream(3)> or | |
110 | L<SSL_accept_stream(3)> to create individual stream SSL objects for sending and | |
111 | receiving application data using L<SSL_read(3)> and L<SSL_write(3)>. | |
112 | ||
113 | To use multi-stream mode, call L<SSL_set_default_stream_mode(3)> with an | |
114 | argument of B<SSL_DEFAULT_STREAM_MODE_NONE>; this function must be called prior | |
115 | to initiating the connection. The default stream mode cannot be changed after | |
116 | initiating a connection. | |
117 | ||
118 | When multi-stream mode is used, meaning that no default stream is associated | |
119 | with the connection, calls to API functions which are defined as operating on a | |
120 | QUIC stream fail if called on the QUIC connection SSL object. For example, calls | |
121 | such as L<SSL_write(3)> or L<SSL_get_stream_id(3)> will fail. | |
122 | ||
f89c2a99 HL |
123 | =head1 CHANGES TO EXISTING APIS |
124 | ||
125 | Most SSL APIs, such as L<SSL_read(3)> and L<SSL_write(3)>, function as they do | |
126 | for TLS connections and do not have changed semantics, with some exceptions. The | |
127 | changes to the semantics of existing APIs are as follows: | |
128 | ||
129 | =over 4 | |
130 | ||
131 | =item | |
132 | ||
133 | Since QUIC uses UDP, L<SSL_set_bio(3)>, L<SSL_set0_rbio(3)> and | |
134 | L<SSL_set0_wbio(3)> function as before, but must now receive a BIO with datagram | |
4b4e246c | 135 | semantics. There are broadly four options for applications to use as a network |
f89c2a99 HL |
136 | BIO: |
137 | ||
138 | =over 4 | |
139 | ||
140 | =item | |
141 | ||
142 | L<BIO_s_datagram(3)>, recommended for most applications, replaces | |
143 | L<BIO_s_socket(3)> and provides a UDP socket. | |
144 | ||
145 | =item | |
146 | ||
4b4e246c | 147 | L<BIO_s_dgram_pair(3)> provides BIO pair-like functionality but with datagram |
f89c2a99 HL |
148 | semantics, and is recommended for existing applications which use a BIO pair or |
149 | memory BIO to manage libssl's communication with the network. | |
150 | ||
151 | =item | |
152 | ||
4b4e246c HL |
153 | L<BIO_s_dgram_mem(3)> provides a simple memory BIO-like interface but with |
154 | datagram semantics. Unlike L<BIO_s_dgram_pair(3)>, it is unidirectional. | |
155 | ||
156 | =item | |
157 | ||
f89c2a99 HL |
158 | An application may also choose to implement a custom BIO. The new |
159 | L<BIO_sendmmsg(3)> and L<BIO_recvmmsg(3)> APIs must be supported. | |
160 | ||
161 | =back | |
162 | ||
163 | =item | |
164 | ||
165 | L<SSL_set_fd(3)>, L<SSL_set_rfd(3)> and L<SSL_set_wfd(3)> traditionally | |
166 | instantiate a L<BIO_s_socket(3)>. For QUIC, these functions instead instantiate | |
167 | a L<BIO_s_datagram(3)>. This is equivalent to instantiating a | |
168 | L<BIO_s_datagram(3)> and using L<SSL_set0_rbio(3)> and L<SSL_set0_wbio(3)>. | |
169 | ||
170 | =item | |
171 | ||
4b4e246c HL |
172 | Traditionally, whether the application-level I/O APIs (such as L<SSL_read(3)> |
173 | and L<SSL_write(3)> operated in a blocking fashion was directly correlated with | |
174 | whether the underlying network socket was configured in a blocking fashion. This | |
175 | is no longer the case; applications must explicitly configure the desired | |
176 | application-level blocking mode using L<SSL_set_blocking_mode(3)>. See | |
177 | L<SSL_set_blocking_mode(3)> for details. | |
178 | ||
179 | =item | |
180 | ||
181 | Network-level I/O must always be performed in a nonblocking manner. The | |
182 | application can still enjoy blocking semantics for calls to application-level | |
183 | I/O functions such as L<SSL_read(3)> and L<SSL_write(3)>, but the underlying | |
184 | network BIO provided to QUIC (such as a L<BIO_s_datagram(3)>) must be configured | |
185 | in nonblocking mode. For application-level blocking functionality, see | |
186 | L<SSL_set_blocking_mode(3)>. | |
187 | ||
188 | =item | |
189 | ||
f89c2a99 HL |
190 | L<BIO_new_ssl_connect(3)> has been changed to automatically use a |
191 | L<BIO_s_datagram(3)> when used with QUIC, therefore applications which use this | |
192 | do not need to change the BIO they use. | |
193 | ||
194 | =item | |
195 | ||
196 | L<BIO_new_buffer_ssl_connect(3)> cannot be used with QUIC and applications must | |
197 | change to use L<BIO_new_ssl_connect(3)> instead. | |
198 | ||
199 | =item | |
200 | ||
201 | L<SSL_shutdown(3)> has significant changes in relation to how QUIC connections | |
202 | must be shut down. In particular, applications should be advised that the full | |
203 | RFC-conformant QUIC shutdown process may take an extended amount of time. This | |
204 | may not be suitable for short-lived processes which should exit immediately | |
205 | after their usage of a QUIC connection is completed. A rapid shutdown mode | |
206 | is available for such applications. For details, see L<SSL_shutdown(3)>. | |
207 | ||
208 | =item | |
209 | ||
210 | L<SSL_want(3)>, L<SSL_want_read(3)> and L<SSL_want_write(3)> no longer reflect | |
211 | the I/O state of the network BIO passed to the QUIC SSL object, but instead | |
212 | reflect the flow control state of the QUIC stream associated with the SSL | |
213 | object. | |
214 | ||
215 | When used in nonblocking mode, B<SSL_ERROR_WANT_READ> indicates that the | |
216 | receive part of a QUIC stream does not currently have any more data available to | |
217 | be read, and B<SSL_ERROR_WANT_WRITE> indicates that the stream's internal buffer | |
218 | is full. | |
219 | ||
220 | To determine if the QUIC implementation currently wishes to be informed of | |
221 | incoming network datagrams, use the new function L<SSL_net_read_desired(3)>; | |
222 | likewise, to determine if the QUIC implementation currently wishes to be | |
223 | informed when it is possible to transmit network datagrams, use the new function | |
224 | L<SSL_net_write_desired(3)>. Only applications which wish to manage their own event | |
225 | loops need to use these functions; see B<APPLICATION-DRIVEN EVENT LOOPS> for | |
226 | further discussion. | |
227 | ||
228 | =item | |
229 | ||
4b4e246c HL |
230 | The use of ALPN is mandatory when using QUIC. Attempts to connect without |
231 | configuring ALPN will fail. For information on how to configure ALPN, see | |
232 | L<SSL_set_alpn_protos(3)>. | |
233 | ||
234 | =item | |
235 | ||
236 | Whether QUIC operates in a client or server mode is determined by the | |
237 | B<SSL_METHOD> used, rather than by calls to L<SSL_set_connect_state(3)> or | |
238 | L<SSL_set_accept_state(3)>. It is not necessary to call either of | |
239 | L<SSL_set_connect_state(3)> or L<SSL_set_accept_state(3)> before connecting, but | |
240 | if either of these are called, the function called must be congruent with the | |
241 | B<SSL_METHOD> being used. Currently, only client mode is supported. | |
242 | ||
243 | =item | |
244 | ||
245 | The L<SSL_set_min_proto_version(3)> and L<SSL_set_max_proto_version(3)> APIs are | |
246 | not used and the values passed to them are ignored, as OpenSSL QUIC currently | |
247 | always uses TLS 1.3. | |
f89c2a99 HL |
248 | |
249 | =item | |
250 | ||
251 | The following libssl functionality is not available when used with QUIC. | |
252 | ||
253 | =over 4 | |
254 | ||
255 | =item | |
256 | ||
257 | Async functionality | |
258 | ||
259 | =item | |
260 | ||
261 | B<SSL_MODE_AUTO_RETRY> | |
262 | ||
263 | =item | |
264 | ||
265 | Record Padding and Fragmentation (L<SSL_set_block_padding(3)>, etc.) | |
266 | ||
267 | =item | |
268 | ||
269 | L<SSL_stateless(3)> support | |
270 | ||
271 | =item | |
272 | ||
273 | SRTP functionality | |
274 | ||
275 | =item | |
276 | ||
277 | TLSv1.3 Early Data | |
278 | ||
279 | =item | |
280 | ||
281 | TLS Next Protocol Negotiation cannot be used and is superseded by ALPN, which | |
282 | must be used instead. The use of ALPN is mandatory with QUIC. | |
283 | ||
284 | =item | |
285 | ||
286 | Post-Handshake Client Authentication is not available as QUIC prohibits its use. | |
287 | ||
288 | =item | |
289 | ||
290 | QUIC requires the use of TLSv1.3 or later, therefore functionality only relevant | |
291 | to older TLS versions is not available. | |
292 | ||
293 | =item | |
294 | ||
295 | Some cipher suites which are generally available for TLSv1.3 are not available | |
296 | for QUIC, such as B<TLS_AES_128_CCM_8_SHA256>. Your application may need to | |
297 | adjust the list of acceptable cipher suites it passes to libssl. | |
298 | ||
299 | =item | |
300 | ||
301 | CCM mode is not currently supported. | |
302 | ||
303 | =back | |
304 | ||
305 | The following libssl functionality is also not available when used with QUIC, | |
306 | but calls to the relevant functions are treated as no-ops: | |
307 | ||
308 | =over 4 | |
309 | ||
310 | =item | |
311 | ||
312 | Readahead (L<SSL_set_read_ahead(3)>, etc.) | |
313 | ||
314 | =back | |
315 | ||
316 | =back | |
317 | ||
318 | =head1 CONSIDERATIONS FOR EXISTING APPLICATIONS | |
319 | ||
320 | Existing applications seeking to adopt QUIC should apply the following list to | |
321 | determine what changes they will need to make: | |
322 | ||
323 | =over 4 | |
324 | ||
325 | =item | |
326 | ||
327 | An application wishing to use QUIC must use L<OSSL_QUIC_client_method(3)> or | |
328 | L<OSSL_QUIC_client_thread_method(3)> as its SSL method. For more information | |
329 | on the differences between these two methods, see B<THREAD ASSISTED MODE>. | |
330 | ||
331 | =item | |
332 | ||
333 | Determine how to provide QUIC with network access. Determine which of the below | |
334 | apply for your application: | |
335 | ||
336 | =over 4 | |
337 | ||
338 | =item | |
339 | ||
340 | Your application uses L<BIO_s_socket(3)> to construct a BIO which is passed to | |
341 | the SSL object to provide it with network access. | |
342 | ||
343 | Changes needed: Change your application to use L<BIO_s_datagram(3)> instead when | |
4b4e246c | 344 | using QUIC. The socket must be configured in nonblocking mode. You may or may |
ce7a9e23 HL |
345 | not need to use L<SSL_set1_initial_peer_addr(3)> to set the initial peer |
346 | address; see the B<QUIC-SPECIFIC APIS> section for details. | |
f89c2a99 HL |
347 | |
348 | =item | |
349 | ||
350 | Your application uses L<BIO_new_ssl_connect(3)> to | |
351 | construct a BIO which is passed to the SSL object to provide it with network | |
352 | access. | |
353 | ||
354 | Changes needed: No changes needed. Use of QUIC is detected automatically and a | |
355 | datagram socket is created instead of a normal TCP socket. | |
356 | ||
357 | =item | |
358 | ||
359 | Your application uses any other I/O strategy in this list but combines it with a | |
360 | L<BIO_f_buffer(3)>, for example using L<BIO_push(3)>. | |
361 | ||
362 | Changes needed: Disable the usage of L<BIO_f_buffer(3)> when using QUIC. Usage | |
363 | of such a buffer is incompatible with QUIC as QUIC requires datagram semantics | |
364 | in its interaction with the network. | |
365 | ||
366 | =item | |
367 | ||
368 | Your application uses a BIO pair to cause the SSL object to read and write | |
369 | network traffic to a memory buffer. Your application manages the transmission | |
370 | and reception of buffered data itself in a way unknown to libssl. | |
371 | ||
372 | Changes needed: Switch from using a conventional BIO pair to using | |
373 | L<BIO_s_dgram_pair(3)> instead, which has the necessary datagram semantics. You | |
374 | will need to modify your application to transmit and receive using a UDP socket | |
375 | and to use datagram semantics when interacting with the L<BIO_s_dgram_pair(3)> | |
376 | instance. | |
377 | ||
378 | =item | |
379 | ||
380 | Your application uses a custom BIO method to provide the SSL object with network | |
381 | access. | |
382 | ||
383 | Changes needed: The custom BIO must be re-architected to have datagram | |
384 | semantics. L<BIO_sendmmsg(3)> and L<BIO_recvmmsg(3)> must be implemented. These | |
385 | calls must operate in a nonblocking fashion. Optionally, implement the | |
386 | L<BIO_get_rpoll_descriptor(3)> and L<BIO_get_wpoll_descriptor(3)> methods if | |
387 | desired. Implementing these methods is required if blocking semantics at the SSL | |
388 | API level are desired. | |
389 | ||
390 | =back | |
391 | ||
392 | =item | |
393 | ||
394 | An application must explicitly configure whether it wishes to use the SSL APIs | |
395 | in blocking mode or not. Traditionally, an SSL object has automatically operated | |
396 | in blocking or nonblocking mode based on whether the underlying network BIO | |
397 | operates in blocking or nonblocking mode. QUIC requires the use of a | |
398 | nonblocking network BIO, therefore the blocking mode at the application level | |
399 | must be explicitly configured by the application using the new | |
400 | L<SSL_set_blocking_mode(3)> API. The default mode is blocking. If an application | |
401 | wishes to use the SSL object APIs at application level in a nonblocking manner, | |
402 | it must add a call to L<SSL_set_blocking_mode(3)> to disable blocking mode. | |
403 | ||
404 | =item | |
405 | ||
406 | If your application does not choose to use thread assisted mode, it must ensure | |
407 | that it calls an I/O function on the SSL object (for example, L<SSL_read(3)> or | |
041d48c9 HL |
408 | L<SSL_write(3)>), or the new function L<SSL_handle_events(3)>, regularly. If the |
409 | SSL object is used in blocking mode, an ongoing blocking call to an I/O function | |
f89c2a99 HL |
410 | satisfies this requirement. This is required to ensure that timer events |
411 | required by QUIC are handled in a timely fashion. | |
412 | ||
413 | Most applications will service the SSL object by calling L<SSL_read(3)> or | |
414 | L<SSL_write(3)> regularly. If an application does not do this, it should ensure | |
041d48c9 | 415 | that L<SSL_handle_events(3)> is called regularly. |
f89c2a99 | 416 | |
041d48c9 HL |
417 | L<SSL_get_event_timeout(3)> can be used to determine when |
418 | L<SSL_handle_events(3)> must next be called. | |
f89c2a99 HL |
419 | |
420 | If the SSL object is being used with an underlying network BIO which is pollable | |
421 | (such as L<BIO_s_datagram(3)>), the application can use | |
422 | L<SSL_get_rpoll_descriptor(3)>, L<SSL_get_wpoll_descriptor(3)> to obtain | |
041d48c9 HL |
423 | resources which can be used to determine when L<SSL_handle_events(3)> should be |
424 | called due to network I/O. | |
f89c2a99 HL |
425 | |
426 | Applications which use thread assisted mode do not need to be concerned | |
427 | with this requirement, as the QUIC implementation ensures timeout events | |
428 | are handled in a timely manner. See B<THREAD ASSISTED MODE> for details. | |
429 | ||
430 | =item | |
431 | ||
432 | Ensure that your usage of L<SSL_want(3)>, L<SSL_want_read(3)> and | |
433 | L<SSL_want_write(3)> reflects the API changes described in B<CHANGES TO EXISTING | |
434 | APIS>. In particular, you should use these APIs to determine the ability of a | |
435 | QUIC stream to receive or provide application data, not to to determine if | |
436 | network I/O is required. | |
437 | ||
438 | =item | |
439 | ||
440 | Evaluate your application's use of L<SSL_shutdown(3)> in light of the changes | |
441 | discussed in B<CHANGES TO EXISTING APIS>. Depending on whether your application | |
442 | wishes to prioritise RFC conformance or rapid shutdown, consider using the new | |
443 | L<SSL_shutdown_ex(3)> API instead. See B<QUIC-SPECIFIC APIS> for details. | |
444 | ||
445 | =back | |
446 | ||
447 | =head1 RECOMMENDED USAGE IN NEW APPLICATIONS | |
448 | ||
449 | The recommended usage in new applications varies depending on three independent | |
450 | design decisions: | |
451 | ||
452 | =over 4 | |
453 | ||
454 | =item | |
455 | ||
456 | Whether the application will use blocking or nonblocking I/O at the application | |
457 | level (configured using L<SSL_set_blocking_mode(3)>). | |
458 | ||
459 | If the application does nonblocking I/O at the application level it can choose | |
460 | to manage its own polling and event loop; see B<APPLICATION-DRIVEN EVENT LOOPS>. | |
461 | ||
462 | =item | |
463 | ||
464 | Whether the application intends to give the QUIC implementation direct access to | |
465 | a network socket (e.g. via L<BIO_s_datagram(3)>) or whether it intends to buffer | |
466 | transmitted and received datagrams via a L<BIO_s_dgram_pair(3)> or custom BIO. | |
467 | ||
468 | The former is preferred where possible as it reduces latency to the network, | |
469 | which enables QUIC to achieve higher performance and more accurate connection | |
470 | round trip time (RTT) estimation. | |
471 | ||
472 | =item | |
473 | ||
474 | Whether thread assisted mode will be used (see B<THREAD ASSISTED MODE>). | |
475 | ||
476 | =back | |
477 | ||
478 | Simple demos for QUIC usage under these various scenarios can be found at | |
479 | L<https://github.com/openssl/openssl/tree/master/doc/designs/ddd>. | |
480 | ||
481 | Applications which wish to implement QUIC-specific protocols should be aware of | |
482 | the APIs listed under B<QUIC-SPECIFIC APIS> which provide access to | |
483 | QUIC-specific functionality. For example, L<SSL_stream_conclude(3)> can be used | |
484 | to indicate the end of the sending part of a stream, and L<SSL_shutdown_ex(3)> | |
485 | can be used to provide a QUIC application error code when closing a connection. | |
486 | ||
4b4e246c HL |
487 | Regardless of the design decisions chosen above, it is recommended that new |
488 | applications avoid use of the default stream mode and use the multi-stream API | |
489 | by calling L<SSL_set_default_stream_mode(3)>; see the MODES OF OPERATION section | |
490 | for details. | |
491 | ||
f89c2a99 HL |
492 | =head1 QUIC-SPECIFIC APIS |
493 | ||
494 | This section details new APIs which are directly or indirectly related to QUIC. | |
495 | For details on the operation of each API, see the referenced man pages. | |
496 | ||
497 | The following SSL APIs are new but relevant to both QUIC and DTLS: | |
498 | ||
499 | =over 4 | |
500 | ||
041d48c9 | 501 | =item L<SSL_get_event_timeout(3)> |
f89c2a99 HL |
502 | |
503 | Determines when the QUIC implementation should next be woken up via a call to | |
041d48c9 | 504 | L<SSL_handle_events(3)> (or another I/O function such as L<SSL_read(3)> or |
f89c2a99 HL |
505 | L<SSL_write(3)>), if ever. |
506 | ||
507 | This can also be used with DTLS and supersedes L<DTLSv1_get_timeout(3)> for new | |
508 | usage. | |
509 | ||
041d48c9 | 510 | =item L<SSL_handle_events(3)> |
f89c2a99 HL |
511 | |
512 | This is a non-specific I/O operation which makes a best effort attempt to | |
513 | perform any pending I/O or timeout processing. It can be used to advance the | |
514 | QUIC state machine by processing incoming network traffic, generating outgoing | |
515 | network traffic and handling any expired timeout events. Most other I/O | |
516 | functions on an SSL object, such as L<SSL_read(3)> and L<SSL_write(3)> | |
041d48c9 HL |
517 | implicitly perform event handling on the SSL object, so calling this function is |
518 | only needed if no other I/O function is to be called. | |
f89c2a99 HL |
519 | |
520 | This can also be used with DTLS and supersedes L<DTLSv1_handle_timeout(3)> for | |
521 | new usage. | |
522 | ||
523 | =back | |
524 | ||
525 | The following SSL APIs are specific to QUIC: | |
526 | ||
527 | =over 4 | |
528 | ||
529 | =item L<SSL_set_blocking_mode(3)>, L<SSL_get_blocking_mode(3)> | |
530 | ||
531 | Configures whether blocking semantics are used at the application level. This | |
532 | determines whether calls to functions such as L<SSL_read(3)> and L<SSL_write(3)> | |
533 | will block. | |
534 | ||
535 | =item L<SSL_get_rpoll_descriptor(3)>, L<SSL_get_wpoll_descriptor(3)> | |
536 | ||
537 | These functions facilitate operation in nonblocking mode. | |
538 | ||
539 | When an SSL object is being used with an underlying network read BIO which | |
540 | supports polling, L<SSL_get_rpoll_descriptor(3)> outputs an OS resource which | |
541 | can be used to synchronise on network readability events which should result in | |
041d48c9 HL |
542 | a call to L<SSL_handle_events(3)>. L<SSL_get_wpoll_descriptor(3)> works in an |
543 | analogous fashion for the underlying network write BIO. | |
f89c2a99 HL |
544 | |
545 | The poll descriptors provided by these functions need only be used when | |
546 | L<SSL_net_read_desired(3)> and L<SSL_net_write_desired(3)> return 1, respectively. | |
547 | ||
548 | =item L<SSL_net_read_desired(3)>, L<SSL_net_write_desired(3)> | |
549 | ||
550 | These functions facilitate operation in nonblocking mode and are used in | |
551 | conjunction with L<SSL_get_rpoll_descriptor(3)> and | |
552 | L<SSL_get_wpoll_descriptor(3)> respectively. They determine whether the | |
553 | respective poll descriptor is currently relevant for the purposes of polling. | |
554 | ||
ce7a9e23 | 555 | =item L<SSL_set1_initial_peer_addr(3)> |
f89c2a99 | 556 | |
4b4e246c | 557 | This function can be used to set the initial peer address for an outgoing QUIC |
f89c2a99 HL |
558 | connection. This function must be used in the general case when creating an |
559 | outgoing QUIC connection; however, the correct initial peer address can be | |
ce7a9e23 | 560 | autodetected in some cases. See L<SSL_set1_initial_peer_addr(3)> for details. |
f89c2a99 HL |
561 | |
562 | =item L<SSL_shutdown_ex(3)> | |
563 | ||
564 | This augments L<SSL_shutdown(3)> by allowing an application error code to be | |
565 | specified. It also allows a client to decide how quickly it wants a shutdown to | |
566 | be performed, potentially by trading off strict RFC compliance. | |
567 | ||
568 | =item L<SSL_stream_conclude(3)> | |
569 | ||
570 | This allows an application to indicate the normal end of the sending part of a | |
571 | QUIC stream. This corresponds to the FIN flag in the QUIC RFC. The receiving | |
572 | part of a stream remains usable. | |
573 | ||
574 | =item L<SSL_stream_reset(3)> | |
575 | ||
4b4e246c HL |
576 | This allows an application to indicate the non-normal termination of the sending |
577 | part of a stream. This corresponds to the RESET_STREAM frame in the QUIC RFC. | |
f89c2a99 | 578 | |
4b4e246c | 579 | =item L<SSL_get_stream_write_state(3)> and L<SSL_get_stream_read_state(3)> |
f89c2a99 | 580 | |
4b4e246c HL |
581 | This allows an application to determine the current stream states for the |
582 | sending and receiving parts of a stream respectively. | |
f89c2a99 | 583 | |
4b4e246c | 584 | =item L<SSL_get_stream_write_error_code(3)> and L<SSL_get_stream_read_error_code(3)> |
f89c2a99 HL |
585 | |
586 | This allows an application to determine the application error code which was | |
4b4e246c HL |
587 | signalled by a peer which has performed a non-normal stream termination of the |
588 | respective sending or receiving part of a stream, if any. | |
f89c2a99 HL |
589 | |
590 | =item L<SSL_get_conn_close_info(3)> | |
591 | ||
592 | This allows an application to determine the error code which was signalled when | |
593 | the local or remote endpoint terminated the QUIC connection. | |
594 | ||
4b4e246c HL |
595 | =item L<SSL_get0_connection(3)> |
596 | ||
597 | Gets the QUIC connection SSL object from a QUIC stream SSL object. | |
598 | ||
599 | =item L<SSL_is_connection(3)> | |
600 | ||
601 | Returns 1 if a SSL object is not a QUIC stream SSL object. | |
602 | ||
603 | =item L<SSL_get_stream_type(3)> | |
604 | ||
605 | Provides information on the kind of QUIC stream which is attached | |
606 | to the SSL object. | |
607 | ||
608 | =item L<SSL_get_stream_id(3)> | |
609 | ||
610 | Returns the QUIC stream ID which the QUIC protocol has associated with a QUIC | |
611 | stream. | |
612 | ||
613 | =item L<SSL_new_stream(3)> | |
614 | ||
615 | Creates a new QUIC stream SSL object representing a new, locally-initiated QUIC | |
616 | stream. | |
617 | ||
618 | =item L<SSL_accept_stream(3)> | |
619 | ||
620 | Potentially yields a new QUIC stream SSL object representing a new | |
621 | remotely-initiated QUIC stream, blocking until one is available if the | |
622 | connection is configured to do so. | |
623 | ||
624 | =item L<SSL_get_accept_stream_queue_len(3)> | |
625 | ||
626 | Provides information on the number of pending remotely-initiated streams. | |
627 | ||
628 | =item L<SSL_set_incoming_stream_policy(3)> | |
629 | ||
630 | Configures how incoming, remotely-initiated streams are handled. The incoming | |
631 | stream policy can be used to automatically reject streams created by the peer, | |
632 | or allow them to be handled using L<SSL_accept_stream(3)>. | |
633 | ||
634 | =item L<SSL_set_default_stream_mode(3)> | |
635 | ||
636 | Used to configure or disable default stream mode; see the MODES OF OPERATION | |
637 | section for details. | |
638 | ||
f89c2a99 HL |
639 | =back |
640 | ||
641 | The following BIO APIs are not specific to QUIC but have been added to | |
642 | facilitate QUIC-specific requirements and are closely associated with its use: | |
643 | ||
644 | =over 4 | |
645 | ||
646 | =item L<BIO_s_dgram_pair(3)> | |
647 | ||
648 | This is a new BIO method which is similar to a conventional BIO pair but | |
649 | provides datagram semantics. | |
650 | ||
651 | =item L<BIO_get_rpoll_descriptor(3)>, L<BIO_get_wpoll_descriptor(3)> | |
652 | ||
653 | This is a new BIO API which allows a BIO to expose a poll descriptor. This API | |
654 | is used to implement the corresponding SSL APIs L<SSL_get_rpoll_descriptor(3)> | |
655 | and L<SSL_get_wpoll_descriptor(3)>. | |
656 | ||
657 | =item L<BIO_sendmmsg(3)>, L<BIO_recvmmsg(3)> | |
658 | ||
659 | This is a new BIO API which can be implemented by BIOs which implement datagram | |
660 | semantics. It is implemented by L<BIO_s_datagram(3)> and L<BIO_s_dgram_pair(3)>. | |
661 | It is used by the QUIC implementation to send and receive UDP datagrams. | |
662 | ||
663 | =item L<BIO_dgram_set_no_trunc(3)>, L<BIO_dgram_get_no_trunc(3)> | |
664 | ||
665 | By default, L<BIO_s_dgram_pair(3)> has semantics comparable to those of Berkeley | |
666 | sockets being used with datagram semantics. This allows an alternative mode | |
667 | to be enabled in which datagrams will not be silently truncated if they are | |
668 | too large. | |
669 | ||
670 | =item L<BIO_dgram_set_caps(3)>, L<BIO_dgram_get_caps(3)> | |
671 | ||
672 | These functions are used to allow the user of one end of a | |
673 | L<BIO_s_dgram_pair(3)> to indicate its capabilities to the other end of a | |
674 | L<BIO_s_dgram_pair(3)>. In particular, this allows an application to inform the | |
675 | QUIC implementation of whether it is prepared to handle local and/or peer | |
676 | addresses in transmitted datagrams and to provide the applicable information in | |
677 | received datagrams. | |
678 | ||
679 | =item L<BIO_dgram_get_local_addr_cap(3)>, L<BIO_dgram_set_local_addr_enable(3)>, | |
680 | L<BIO_dgram_get_local_addr_enable(3)> | |
681 | ||
682 | Local addressing support refers to the ability of a BIO with datagram semantics | |
683 | to allow a source address to be specified on transmission and to report the | |
684 | destination address on reception. These functions can be used to determine if a | |
685 | BIO can support local addressing and to enable local addressing support if it | |
686 | can. | |
687 | ||
688 | =item L<BIO_err_is_non_fatal(3)> | |
689 | ||
690 | This is used to determine if an error while calling L<BIO_sendmmsg(3)> or | |
691 | L<BIO_recvmmsg(3)> is ephemeral in nature, such as "would block" errors. | |
692 | ||
693 | =back | |
694 | ||
695 | =head1 THREAD ASSISTED MODE | |
696 | ||
697 | The optional thread assisted mode can be used with | |
698 | L<OSSL_QUIC_client_thread_method(3)>. In this mode, a background thread is | |
699 | created automatically. The OpenSSL QUIC implementation then takes responsibility | |
700 | for ensuring that timeout events are handled on a timely basis even if no SSL | |
701 | I/O function such as L<SSL_read(3)> or L<SSL_write(3)> is called by the | |
702 | application for a long time. | |
703 | ||
704 | All necessary locking is handled automatically internally, but the thread safety | |
705 | guarantees for the public SSL API are unchanged. Therefore, an application must | |
706 | still do its own locking if it wishes to make concurrent use of the public SSL | |
707 | APIs. | |
708 | ||
709 | Because this method relies on threads, it is not available on platforms where | |
710 | threading support is not available or not supported by OpenSSL. However, it | |
711 | does provide the simplest mode of usage for an application. | |
712 | ||
713 | The implementation may or may not use a common thread or thread pool to service | |
714 | multiple SSL objects in the same B<SSL_CTX>. | |
715 | ||
f89c2a99 HL |
716 | =head1 APPLICATION-DRIVEN EVENT LOOPS |
717 | ||
718 | OpenSSL's QUIC implementation is designed to facilitate applications which wish | |
719 | to use the SSL APIs in a blocking fashion, but is also designed to facilitate | |
720 | applications which wish to use the SSL APIs in a nonblocking fashion and manage | |
721 | their own event loops and polling directly. This is useful when it is desirable | |
722 | to host OpenSSL's QUIC implementation on top of an application's existing | |
723 | nonblocking I/O infrastructure. | |
724 | ||
725 | This is supported via the concept of poll descriptors; see | |
726 | L<BIO_get_rpoll_descriptor(3)> for details. Broadly, a B<BIO_POLL_DESCRIPTOR> is | |
727 | a structure which expresses some kind of OS resource which can be used to | |
728 | synchronise on I/O events. The QUIC implementation provides a | |
729 | B<BIO_POLL_DESCRIPTOR> based on the poll descriptor provided by the underlying | |
730 | network BIO. This is typically an OS socket handle, though custom BIOs could | |
731 | choose to implement their own custom poll descriptor format. | |
732 | ||
733 | Broadly, an application which wishes to manage its own event loop should | |
734 | interact with the SSL object as follows: | |
735 | ||
736 | =over 4 | |
737 | ||
738 | =item | |
739 | ||
740 | It should provide read and write BIOs with nonblocking datagram semantics to | |
741 | the SSL object using L<SSL_set0_rbio(3)> and L<SSL_set0_wbio(3)>. This could be | |
742 | a BIO abstracting a network socket such as L<BIO_s_datagram(3)>, or a BIO | |
743 | abstracting some kind of memory buffer such as L<BIO_s_dgram_pair(3)>. Use of a | |
744 | custom BIO is also possible. | |
745 | ||
746 | =item | |
747 | ||
748 | It should configure the SSL object into nonblocking mode by calling | |
749 | L<SSL_set_blocking_mode(3)>. | |
750 | ||
751 | =item | |
752 | ||
753 | It should configure the SSL object as desired, set an initial peer as needed | |
ce7a9e23 | 754 | using L<SSL_set1_initial_peer_addr(3)>, and trigger the connection process by |
f89c2a99 HL |
755 | calling L<SSL_connect(3)>. |
756 | ||
757 | =item | |
758 | ||
759 | If the network read and write BIOs provided were pollable (for example, | |
760 | a L<BIO_s_datagram(3)>, or a custom BIO which implements | |
761 | L<BIO_get_rpoll_descriptor(3)> and L<BIO_get_wpoll_descriptor(3)>), it should | |
762 | perform the following steps repeatedly: | |
763 | ||
764 | =over 4 | |
765 | ||
766 | =item | |
767 | ||
768 | The application should call L<SSL_get_rpoll_descriptor(3)> and | |
769 | L<SSL_get_wpoll_descriptor(3)> to identify OS resources which can be used for | |
770 | synchronisation. | |
771 | ||
772 | =item | |
773 | ||
774 | It should call L<SSL_net_read_desired(3)> and L<SSL_net_write_desired(3)> to determine | |
775 | whether the QUIC implementation is currently interested in readability and | |
776 | writability events on the underlying network BIO which was provided, and call | |
041d48c9 | 777 | L<SSL_get_event_timeout(3)> to determine if any timeout event will become |
f89c2a99 HL |
778 | applicable in the future. |
779 | ||
780 | =item | |
781 | ||
782 | It should wait until one of the following events occurs: | |
783 | ||
784 | =over 4 | |
785 | ||
786 | =item | |
787 | ||
788 | The poll descriptor returned by L<SSL_get_rpoll_descriptor(3)> becomes readable | |
789 | (if L<SSL_net_read_desired(3)> returned 1); | |
790 | ||
791 | =item | |
792 | ||
793 | The poll descriptor returned by L<SSL_get_wpoll_descriptor(3)> becomes writable | |
794 | (if L<SSL_net_write_desired(3)> returned 1); | |
795 | ||
796 | =item | |
797 | ||
041d48c9 | 798 | The timeout returned by L<SSL_get_event_timeout(3)> (if any) expires. |
f89c2a99 HL |
799 | |
800 | =back | |
801 | ||
041d48c9 | 802 | Once any of these events occurs, L<SSL_handle_events(3)> should be called. |
f89c2a99 HL |
803 | |
804 | =back | |
805 | ||
806 | =item | |
807 | ||
808 | If the network read and write BIOs provided were not pollable (for example, in | |
809 | the case of L<BIO_s_dgram_pair(3)>), the application is responsible for managing | |
041d48c9 HL |
810 | and synchronising network I/O. It should call L<SSL_handle_events(3)> after it |
811 | writes data to a L<BIO_s_dgram_pair(3)> or otherwise takes action so that the | |
812 | QUIC implementation can read new datagrams via a call to L<BIO_recvmmsg(3)> on | |
813 | the underlying network BIO. The QUIC implementation may output datagrams via a | |
814 | call to L<BIO_sendmmsg(3)> and the application is responsible for ensuring these | |
815 | are transmitted. | |
816 | ||
817 | The application must call L<SSL_get_event_timeout(3)> after every call to | |
818 | L<SSL_handle_events(3)> (or another I/O function on the SSL object), and ensure | |
819 | that a call to L<SSL_handle_events(3)> is performed after the specified timeout | |
820 | (if any). | |
f89c2a99 HL |
821 | |
822 | =back | |
823 | ||
824 | =head1 SEE ALSO | |
825 | ||
041d48c9 HL |
826 | L<SSL_handle_events(3)>, L<SSL_get_event_timeout(3)>, |
827 | L<SSL_net_read_desired(3)>, L<SSL_net_write_desired(3)>, | |
828 | L<SSL_get_rpoll_descriptor(3)>, L<SSL_get_wpoll_descriptor(3)>, | |
829 | L<SSL_set_blocking_mode(3)>, L<SSL_shutdown_ex(3)>, | |
ce7a9e23 | 830 | L<SSL_set1_initial_peer_addr(3)>, L<SSL_stream_conclude(3)>, |
041d48c9 HL |
831 | L<SSL_stream_reset(3)>, L<SSL_get_stream_read_state(3)>, |
832 | L<SSL_get_stream_read_error_code(3)>, L<SSL_get_conn_close_info(3)>, | |
833 | L<SSL_get0_connection(3)>, L<SSL_get_stream_type(3)>, L<SSL_get_stream_id(3)>, | |
834 | L<SSL_new_stream(3)>, L<SSL_accept_stream(3)>, | |
835 | L<SSL_set_incoming_stream_policy(3)>, L<SSL_set_default_stream_mode(3)> | |
f89c2a99 HL |
836 | |
837 | =head1 COPYRIGHT | |
838 | ||
839 | Copyright 2022 The OpenSSL Project Authors. All Rights Reserved. | |
840 | ||
841 | Licensed under the Apache License 2.0 (the "License"). You may not use | |
842 | this file except in compliance with the License. You can obtain a copy | |
843 | in the file LICENSE in the source distribution or at | |
844 | L<https://www.openssl.org/source/license.html>. | |
845 | ||
846 | =cut |