Hakase/openssl-custom
1
0 Fork 0
Code Issues Pull Requests Releases Wiki Activity

Latest update - https://github.com/openssl/openssl/commit/46d085096c6ead624c61e4b8b301421301511e64

Browse Source
This commit is contained in:
Hakase
2018-09-22 13:24:05 +09:00
parent ebab062ce0
commit 75a46534f3
35 changed files with 384 additions and 100 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/man3/SSL_set_shutdown.pod
+4 -4
View File
@@ -30,12 +30,12 @@ No shutdown setting, yet.
=item SSL_SENT_SHUTDOWN
A "close notify" shutdown alert was sent to the peer, the connection is being
A close_notify shutdown alert was sent to the peer, the connection is being
considered closed and the session is closed and correct.
=item SSL_RECEIVED_SHUTDOWN
A shutdown alert was received form the peer, either a normal "close notify"
A shutdown alert was received form the peer, either a normal close_notify
or a fatal error.
=back
@@ -47,13 +47,13 @@ the ssl session. If the session is still open, when
L<SSL_clear(3)> or L<SSL_free(3)> is called,
it is considered bad and removed according to RFC2246.
The actual condition for a correctly closed session is SSL_SENT_SHUTDOWN
(according to the TLS RFC, it is acceptable to only send the "close notify"
(according to the TLS RFC, it is acceptable to only send the close_notify
alert but to not wait for the peer's answer, when the underlying connection
is closed).
SSL_set_shutdown() can be used to set this state without sending a
close alert to the peer (see L<SSL_shutdown(3)>).
If a "close notify" was received, SSL_RECEIVED_SHUTDOWN will be set,
If a close_notify was received, SSL_RECEIVED_SHUTDOWN will be set,
for setting SSL_SENT_SHUTDOWN the application must however still call
L<SSL_shutdown(3)> or SSL_set_shutdown() itself.