Stephane Bortzmeyer <stephane@sources.org> writes: > On Mon, Oct 11, 2021 at 08:57:59AM +0200, > Omar Polo <op@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 are using? Thanks for chiming in and also for sharing the excerpt about close_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. >
---
Previous in thread (7 of 50): 🗣️ Chris McGowan (cmcgowan9990 (a) gmail.com)
Next in thread (9 of 50): 🗣️ Alan Bunbury (gemini (a) bunburya.eu)