Lines Matching full:we
21 We use a blocking socket for the purposes of this example. This means that
24 For example, this can happen if we have sent our request, but we are still
37 We assume that you already have OpenSSL installed on your system; that you
46 The first step is to create an B<SSL_CTX> object for our client. We use the
47 L<SSL_CTX_new(3)> function for this purpose. We could alternatively use
48 L<SSL_CTX_new_ex(3)> if we want to associate the B<SSL_CTX> with a particular
50 B<OSSL_LIB_CTX>). We pass as an argument the return value of the function
57 * Create an SSL_CTX which we can use to create SSL objects from. We
58 * want an SSL_CTX for creating clients so we use TLS_client_method()
67 Since we are writing a client we must ensure that we verify the server's
68 certificate. We do this by calling the L<SSL_CTX_set_verify(3)> function and
84 default store so we call L<SSL_CTX_set_default_verify_paths(3)>.
92 We would also like to restrict the TLS versions that we are willing to accept to
94 avoided where possible. We can do that using
99 * avoided if possible. We require a minimum TLS version of TLSv1.2.
106 That is all the setup that we need to do for the B<SSL_CTX>, so next we need to
108 we might expect to be creating more than one TLS connection over time. In that
109 case we would expect to reuse the B<SSL_CTX> that we already created each time.
115 function and passing the B<SSL_CTX> we created as an argument.
183 * we can connect to.
187 * Create a TCP socket. We could equally use non-OpenSSL calls such
189 * functions. But for portability reasons and also so that we get
190 * errors on the OpenSSL stack in the event of a failure we use
204 /* We have a connected socket so break out of the loop */
208 /* Free the address information resources we allocated earlier */
220 sockets - which is exactly what we want for this example.
222 Once the socket has been created and connected we need to associate it with a
246 Finally we associate the B<SSL> object we created earlier with the B<BIO> using
257 We have already connected our underlying socket to the server, but the client
259 purposes and we need to set the hostname for each one.
266 one we want to connect to. Without this information we may get a handshake
267 failure, or we may get connected to the "default" server which may not be the
268 one we were expecting.
270 To set the SNI hostname data we call the L<SSL_set_tlsext_host_name(3)> function
274 * Tell the server during the handshake which hostname we are attempting
285 Secondly, we need to tell OpenSSL what hostname we expect to see in the
287 we asked for in the original request. This is important because, without this,
288 we do not verify that the hostname in the certificate is what we expect it to be
290 itself. We do this via the L<SSL_set1_host(3)> function:
293 * Ensure we check during certificate verification that the server has
294 * supplied a certificate for the hostname that we were expecting.
303 All of the above steps must happen before we attempt to perform the handshake
308 Before we can start sending or receiving application data over a TLS connection
309 the TLS handshake must be performed. We can do this explicitly via the
316 * If the failure is due to a verification error we can get more
326 value of 1 is considered a success. For a simple blocking client we only need
328 indicates that we have failed to connect to the server.
332 signed by a CA in our trusted certificate store. We can use the
336 cause). Otherwise we use the L<X509_verify_cert_error_string(3)> function to get
341 Once the handshake is complete we are able to send and receive application data.
343 application level protocol. In this example we are using HTTP 1.0 which is a
348 To send data to the server we use the L<SSL_write_ex(3)> function and to receive
349 data from the server we use the L<SSL_read_ex(3)> function. In HTTP 1.0 the
351 we are connecting to. For simplicity, we write the HTTP request in three
352 chunks. First we write the start of the request. Secondly we write the hostname
353 we are sending the request to. Finally we send the end of the request.
374 If it is successful then we can proceed to waiting for a response from the
381 * Get up to sizeof(buf) bytes of the response. We keep reading until the
387 * that it is NUL terminated so we use fwrite() to write the exact
388 * number of bytes that we read. The data could be non-printable or
390 * we're going to print it to stdout anyway.
394 /* In case the response didn't finish with a newline we add one now */
398 We use the L<SSL_read_ex(3)> function to read the response. We don't know
399 exactly how much data we are going to receive back so we enter a loop reading
400 blocks of data from the server and printing each block that we receive to the
409 in a 0 return value from L<SSL_read_ex(3)> and we need to use the function
413 * Check whether we finished the while loop above normally or as the
415 * code we received from the SSL_read_ex() call. It must be 0 in order
427 If L<SSL_get_error(3)> returns B<SSL_ERROR_ZERO_RETURN> then we know that the
432 Once we have finished reading data from the server then we are ready to close
433 the connection down. We do this via the L<SSL_shutdown(3)> function which has
435 the server saying that we have finished writing data:
438 * The peer already shutdown gracefully (we know this because of the
439 * SSL_ERROR_ZERO_RETURN above). We should do the same back.
445 * because that means "we've sent a close_notify and we're waiting
446 * for one back". But we already know we got one from the peer
455 precisely a return value of 1 means that we have sent a "close_notify" alert to
456 the server, and that we have also received one back. A return value of 0 means
457 that we have sent a "close_notify" alert to the server, but we have not yet
460 received. However in this case we already know that the server has sent us a
461 "close_notify" because of the SSL_ERROR_ZERO_RETURN that we received from the
462 call to L<SSL_read_ex(3)>. So this scenario should never happen in practice. We
467 Before the application exits we have to clean up some memory that we allocated.
468 If we are exiting due to an error we might also want to display further
475 * If something bad happened then we will dump the contents of the
483 * Free the resources we allocated. We do not free the BIO object here
485 * via SSL_set_bio(). The BIO will be freed when we free the SSL object.
491 To display errors we make use of the L<ERR_print_errors_fp(3)> function which
495 We need to free up the B<SSL> object that we created for the connection via the
496 L<SSL_free(3)> function. Also, since we are not going to be creating any more
497 TLS connections we must also free up the B<SSL_CTX> via a call to
556 The "unable to get local issuer certificate" we saw in the example above means
557 that we have been unable to find the issuer of the server's certificate (or one