[2] closure alert は、 TLS の接続を閉じることを表すメッセージです。
AlertDescription の値 close_notify (0) は、
closure alert を表します。
[3] クライアントと鯖は、truncation attack の防止のため、
接続を終える旨を共有しなければなりません >>1。
closure alert (AlertDescription = close_notify (0)
のメッセージ) をこれに用います。他の fatal alert
を転送した場合を除き、クライアントや鯖は、接続の書き込み側を閉じる前に
close_notify alert を送信する必要があります >>1。
[6] close_notify alert は、送信者が当該接続においてそれ以上はメッセージを送らないことを意味します
>>1。クライアントと鯖のどちらから送信しても構いません
>>1。
[5] closure alert より後に受信したデータは、無視します >>1。
[7] closure alert を受信したら、 close_notity alert
を返送すると共に、直ちに接続を閉じ、書き残したものがあれば捨てなければなりません >>1。
[8] close_notify を先に送った側は、返送の到着を待たずに接続の読み込み側を閉じて構いません >>1。
TLS を使う応用プロトコルが TLS が閉じられた後に下位の輸送路を使ってデータを転送する場合には、
TLS の接続が閉じられたと応用プロトコル側に通知するのは
close_notify alert が返送された後としなければなりません >>1。
応用プロトコルがそれ以上データを転送せずに下位の輸送路を閉じるだけの場合には、
close_notify alert の返送を待たずとも構いません >>1。
[4] 接続を正しく閉じることに失敗しても、TLSセッションを再開することを妨げるものではありません >>1。
[11] alert level は closure alert では無視されるようです。
[9] アプリケーション層プロトコルは、 TLS を使う場合に closure alert との関係 (どのタイミングで closure alert を送信するのか、 closure alert を受信した場合にアプリケーション層プロトコル側でどうエラー処理するのか、 TLS より下の層のプロトコルの接続を閉じるタイミングなど) を規定する必要があります。
Requiring close_notify isn't possible because so many sites don't send it
However, like all other browsers, it doesn't implement the mandatory TLS closure alert enforcement from TLS 1.1 to prevent truncation attacks at the transport layer.
For example, https://www.oracle.com sends the close notify as I expect it, but https://www.google.com does not - it just closes the connection after my app sends the close notify.
OpenSSL, and thus implementations based on OpenSSL (clients and server), tend to no longer send close_notify messages; they just drop the connection. The main reason is that in existing Web servers and clients, connections are managed in a pool that closes them after some inactivity delay; that pool manages low-level sockets and has no notion of what SSL could be; thus, the SSL layer has no way to send (or wait for) an explicit close_notify.
[18] Chrome と IE は、正常時も異常時も、 alert を送らないで TCP接続を閉じるようです。
[19] Firefox は正常時は close_notify、異常時は適当なエラーの alert
を送って閉じるようです。
相手の TLS alert は待たずにTCPを閉じるようです。
Both GnuTLS and CDSA (Adium's SSL plugin) check whether a TLS connection has been closed properly by checking if the server sent a close_notify alert first. [https://bugzilla.mozilla.org/show_bug.cgi?id=508698 NSS doesn't]. If that alert wasn't sent, GnuTLS and CDSA consider it a fatal error, which for the HTTPS handler means the response is completely discarded. That's what's happening here with Yahoo: their HTTPS server closes the connection without sending close_notify first.
[21] 508698 – SSL_SecureRecv returns 0 rather than an error if the peer closes the TCP connection without sending an SSL close_notify alert ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=508698
[22] /docs/manmaster/man3/SSL_CTX_set_quiet_shutdown.html (OpenSSL Foundation, Inc.著, ) https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_quiet_shutdown.html