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