💾 Archived View for rawtext.club › ~sloum › geminilist › 007289.gmi captured on 2024-03-21 at 15:56:14. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Omar Polo op at omarpolo.com
Mon Oct 11 15:13:00 BST 2021
- - - - - - - - - - - - - - - - - - -
Stephane Bortzmeyer <stephane at sources.org> writes:
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 (application
close). Even 36.8 % of those who return status 20 are in that case."
It's worst than what I thought! We know what software this servers areusing?
Thanks for chiming in and also for sharing the excerpt aboutclose_notify :)
The future RFC on HTTP (completely rewritten and reorganised) has a
nice 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.