💾 Archived View for rawtext.club › ~sloum › geminilist › 007284.gmi captured on 2023-11-04 at 12:39:31. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Stephane Bortzmeyer stephane at sources.org
Mon Oct 11 09:56:46 BST 2021
- - - - - - - - - - - - - - - - - - -
On Mon, Oct 11, 2021 at 08:57:59AM +0200, Omar Polo <op at omarpolo.com> wrote a message of 87 lines which said:
3. close_notify
Is it still a problem? :D
Yes :-(
(Sometimes I've left dangling questions like this hoping for Bortzmeyer
to chime in and share some stats. In the past it worked, hope he share
some this time too ;-)
"50.4 % of URLs do NOT send a proper TLS shutdown (applicationclose). Even 36.8 % of those who return status 20 are in that case."
The future RFC on HTTP (completely rewritten and reorganised) has anice explanation:
9.8. TLS Connection Closure
TLS uses an exchange of closure alerts prior to (non-error) connection closure to provide secure connection closure; see Section 6.1 of [TLS13]. When a valid closure alert is received, an implementation can be assured that no further data will be received on that connection.
When an implementation knows that it has sent or received all the message data that it cares about, typically by detecting HTTP message boundaries, it might generate an "incomplete close" by sending a closure alert and then closing the connection without waiting to receive the corresponding closure alert from its peer.
An incomplete close does not call into question the security of the data already received, but it could indicate that subsequent data might have been truncated. As TLS is not directly aware of HTTP message framing, it is necessary to examine the HTTP data itself to determine whether messages were complete. Handling of incomplete messages is defined in Section 8.
When encountering an incomplete close, a client SHOULD treat as completed all requests for which it has received as much data as specified in the Content-Length header or, when a Transfer-Encoding of chunked is used, for which the terminal zero-length chunk has been received. A response that has neither chunked transfer coding nor Content-Length is complete only if a valid closure alert has been received. Treating an incomplete message as complete could expose implementations to attack.
A client detecting an incomplete close SHOULD recover gracefully.
Clients MUST send a closure alert before closing the connection. Clients that do not expect to receive any more data MAY choose not to wait for the server's closure alert and simply close the connection, thus generating an incomplete close on the server side.
Servers SHOULD be prepared to receive an incomplete close from the client, since the client can often determine when the end of server data is.
Servers MUST attempt to initiate an exchange of closure alerts with the client before closing the connection. Servers MAY close the connection after sending the closure alert, thus generating an incomplete close on the client side.
And also:
11.3. Message Integrity... Care is needed however to ensure that connection closure cannot be used to truncate messages (see Section 9.8). User agents might refuse to accept incomplete messages or treat them specially. For example, a browser being used to view medical history or drug interaction information needs to indicate to the user when such information is detected by the protocol to be incomplete, expired, or corrupted during transfer. Such mechanisms might be selectively enabled via user agent extensions or the presence of message integrity metadata in a response.