VirtualBox

Ignore:
Timestamp:
Mar 3, 2022 7:17:34 PM (3 years ago)
Author:
vboxsync
svn:sync-xref-src-repo-rev:
150325
Message:

libs/openssl-3.0.1: started applying and adjusting our OpenSSL changes to 3.0.1. bugref:10128

Location:
trunk/src/libs/openssl-3.0.1
Files:
2 edited

Legend:

Unmodified
Added
Removed

  • trunk/src/libs/openssl-3.0.1

    • Property svn:mergeinfo

      •  

        old new  
        1212/vendor/openssl/1.1.1c:131722-131725
        1313/vendor/openssl/1.1.1k:145841-145843
         14/vendor/openssl/3.0.1:150323-150324
         15/vendor/openssl/current:147554-150322

  • trunk/src/libs/openssl-3.0.1/doc/man3/SSL_shutdown.pod

    r91772 r94082  
    1515SSL_shutdown() shuts down an active TLS/SSL connection. It sends the
    1616close_notify shutdown alert to the peer.
    17 
    18 =head1 NOTES
    1917
    2018SSL_shutdown() tries to send the close_notify shutdown alert to the peer.
    … …  
    5250It is not possible to call SSL_write() after calling SSL_shutdown().
    5351The read direction is closed by the peer.
     52
     53The behaviour of SSL_shutdown() additionally depends on the underlying BIO.
     54If the underlying BIO is B<blocking>, SSL_shutdown() will only return once the
     55handshake step has been finished or an error occurred.
     56
     57If the underlying BIO is B<nonblocking>, SSL_shutdown() will also return
     58when the underlying BIO could not satisfy the needs of SSL_shutdown()
     59to continue the handshake. In this case a call to SSL_get_error() with the
     60return value of SSL_shutdown() will yield B<SSL_ERROR_WANT_READ> or
     61B<SSL_ERROR_WANT_WRITE>. The calling process then must repeat the call after
     62taking appropriate action to satisfy the needs of SSL_shutdown().
     63The action depends on the underlying BIO. When using a nonblocking socket,
     64nothing is to be done, but select() can be used to check for the required
     65condition. When using a buffering BIO, like a BIO pair, data must be written
     66into or retrieved out of the BIO before being able to continue.
     67
     68After SSL_shutdown() returned 0, it is possible to call SSL_shutdown() again
     69to wait for the peer's close_notify alert.
     70SSL_shutdown() will return 1 in that case.
     71However, it is recommended to wait for it using SSL_read() instead.
     72
     73SSL_shutdown() can be modified to only set the connection to "shutdown"
     74state but not actually send the close_notify alert messages,
     75see L<SSL_CTX_set_quiet_shutdown(3)>.
     76When "quiet shutdown" is enabled, SSL_shutdown() will always succeed
     77and return 1.
     78Note that this is not standard compliant behaviour.
     79It should only be done when the peer has a way to make sure all
     80data has been received and doesn't wait for the close_notify alert
     81message, otherwise an unexpected EOF will be reported.
     82
     83There are implementations that do not send the required close_notify alert.
     84If there is a need to communicate with such an implementation, and it's clear
     85that all data has been received, do not wait for the peer's close_notify alert.
     86Waiting for the close_notify alert when the peer just closes the connection
     87will result in an error being generated.
     88The error can be ignored using the B<SSL_OP_IGNORE_UNEXPECTED_EOF>.
     89For more information see L<SSL_CTX_set_options(3)>.
    5490
    5591=head2 First to close the connection
    … …  
    90126SSL_get_shutdown() (see also L<SSL_set_shutdown(3)> call.
    91127
    92 =head1 NOTES
    93 
    94 The behaviour of SSL_shutdown() additionally depends on the underlying BIO.
    95 If the underlying BIO is B<blocking>, SSL_shutdown() will only return once the
    96 handshake step has been finished or an error occurred.
    97 
    98 If the underlying BIO is B<nonblocking>, SSL_shutdown() will also return
    99 when the underlying BIO could not satisfy the needs of SSL_shutdown()
    100 to continue the handshake. In this case a call to SSL_get_error() with the
    101 return value of SSL_shutdown() will yield B<SSL_ERROR_WANT_READ> or
    102 B<SSL_ERROR_WANT_WRITE>. The calling process then must repeat the call after
    103 taking appropriate action to satisfy the needs of SSL_shutdown().
    104 The action depends on the underlying BIO. When using a nonblocking socket,
    105 nothing is to be done, but select() can be used to check for the required
    106 condition. When using a buffering BIO, like a BIO pair, data must be written
    107 into or retrieved out of the BIO before being able to continue.
    108 
    109 After SSL_shutdown() returned 0, it is possible to call SSL_shutdown() again
    110 to wait for the peer's close_notify alert.
    111 SSL_shutdown() will return 1 in that case.
    112 However, it is recommended to wait for it using SSL_read() instead.
    113 
    114 SSL_shutdown() can be modified to only set the connection to "shutdown"
    115 state but not actually send the close_notify alert messages,
    116 see L<SSL_CTX_set_quiet_shutdown(3)>.
    117 When "quiet shutdown" is enabled, SSL_shutdown() will always succeed
    118 and return 1.
    119 Note that this is not standard compliant behaviour.
    120 It should only be done when the peer has a way to make sure all
    121 data has been received and doesn't wait for the close_notify alert
    122 message, otherwise an unexpected EOF will be reported.
    123 
    124 There are implementations that do not send the required close_notify alert.
    125 If there is a need to communicate with such an implementation, and it's clear
    126 that all data has been received, do not wait for the peer's close_notify alert.
    127 Waiting for the close_notify alert when the peer just closes the connection will
    128 result in an error being generated.
    129 
    130128=head1 RETURN VALUES
    131129
    … …  
    164162L<SSL_get_error(3)>, L<SSL_connect(3)>,
    165163L<SSL_accept(3)>, L<SSL_set_shutdown(3)>,
    166 L<SSL_CTX_set_quiet_shutdown(3)>,
     164L<SSL_CTX_set_quiet_shutdown(3)>, L<SSL_CTX_set_options(3)>
    167165L<SSL_clear(3)>, L<SSL_free(3)>,
    168166L<ssl(7)>, L<bio(7)>
    … …  
    172170Copyright 2000-2020 The OpenSSL Project Authors. All Rights Reserved.
    173171
    174 Licensed under the OpenSSL license (the "License").  You may not use
     172Licensed under the Apache License 2.0 (the "License").  You may not use
    175173this file except in compliance with the License.  You can obtain a copy
    176174in the file LICENSE in the source distribution or at
Note: See TracChangeset for help on using the changeset viewer.

© 2025 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy Automated Access Etiquette