Lines Matching full:we
23 We assume that you already have OpenSSL installed on your system; that you
29 understanding of UDP/IP and sockets. The example code that we build in this
32 this one will be discussed so we also assume that you have run through and
46 In the TLS tutorial (L<ossl-guide-tls-client-block(7)>) we created an B<SSL_CTX>
48 TLS connection. A QUIC connection works in exactly the same way. We first create
53 client. This is done in the same way as before except that we use a different
60 mode", see L<ossl-guide-quic-introduction(7)>). For this tutorial we will be
61 using L<OSSL_QUIC_client_method(3)> because we will not be leaving the QUIC
65 * Create an SSL_CTX which we can use to create SSL objects from. We
66 * want an SSL_CTX for creating clients so we use OSSL_QUIC_client_method()
75 The other setup steps that we applied to the B<SSL_CTX> for TLS also apply to
76 QUIC except for restricting the TLS versions that we are willing to accept. The
89 example code is much the same as for TLS. We use the L<BIO_lookup_ex(3)> and
90 L<BIO_socket(3)> helper functions as we did in the previous tutorial except that
91 we pass B<SOCK_DGRAM> as an argument to indicate UDP (instead of B<SOCK_STREAM>
103 * we can connect to.
107 * Create a TCP socket. We could equally use non-OpenSSL calls such
109 * functions. But for portability reasons and also so that we get
110 * errors on the OpenSSL stack in the event of a failure we use
142 /* Free the address information resources we allocated earlier */
146 that we used for TLS.
148 Firstly, we set the socket into nonblocking mode. This must always be done for
149 an OpenSSL QUIC application. This may be surprising considering that we are
154 Secondly, we take note of the IP address of the peer that we are connecting to.
155 We store that information away. We will need it later.
163 As for our TLS client, once the socket has been created and connected we need to
185 we used for our TLS client. This is again due to the fact that QUIC uses UDP
191 As in the TLS tutorial we need to set the server's hostname both for SNI (Server
204 simple client that we developed in L<ossl-guide-tls-client-block(7)> did not use
218 HTTP/1.0. We will use the same for this example. Unlike most OpenSSL functions
224 is being connected to. In L</Creating the socket and BIO> above we saved that
225 address away for future use. Now we need to use it via the
234 Note that we will need to free the B<peer_addr> value that we allocated via
241 Once initial setup of the B<SSL> object is complete then we perform the
242 handshake via L<SSL_connect(3)> in exactly the same way as we did for the TLS
243 client, so we won't repeat it here.
245 We can also perform data transfer using a default QUIC stream that is
246 automatically associated with the B<SSL> object for us. We can transmit data
248 way as for TLS. The main difference is that we have to account for failures
253 First, we write the entire request to the stream. We also must make sure to
254 signal to the server that we have finished writing. This can be done by passing
256 L<SSL_stream_conclude(3)>. Since the first way is more efficient, we choose to
274 Then, we read the response from the server.
277 * Get up to sizeof(buf) bytes of the response. We keep reading until the
283 * that it is NUL terminated so we use fwrite() to write the exact
284 * number of bytes that we read. The data could be non-printable or
286 * we're going to print it to stdout anyway.
290 /* In case the response didn't finish with a newline we add one now */
294 * Check whether we finished the while loop above normally or as the
296 * code we received from the SSL_read_ex() call. It must be 0 in order
335 fatal error. We can use L<SSL_get_stream_read_state(3)> to determine whether the
340 In the TLS tutorial we knew that the server had finished sending data because
344 we knew that this meant that the server had sent a "close_notify" alert. No
354 In this tutorial, once we have finished reading data from the server on the one
355 stream that we are using, we will close the connection down. As before we do
372 The shutdown process is in two stages. In the first stage we wait until all the
373 data we have buffered for sending on any stream has been successfully sent and
374 acknowledged by the peer, and then we send a CONNECTION_CLOSE to the peer to