En la práctica, muchos servidores HTTPS ampliamente implementados cierran las conexiones de forma abrupta, sin previo aviso, y en particular sin el close_notify . Lo hacen porque quieren eliminar las conexiones que han estado inactivas durante mucho tiempo (por ejemplo, más de 30 segundos), y quieren hacerlo incluso si la conexión estaba inactiva porque el cliente se ha ido (por ejemplo, se ha caído o se ha retirado de ella). alcance del punto de acceso WiFi, o cualquier otra situación similar) y no reconocerá el close_notify .
Sería tecnológicamente factible que un servidor envíe un close_notify incluso a un cliente muerto, y aún así limpie los recursos correctamente, pero a muchos diseñadores de servidores les resulta más fácil simplemente no enviar el close_notify (esto permite mantener el Motor SSL y la gestión de socket por separado). Esto está en contradicción con el estándar TLS , pero sabemos que los desarrolladores del mundo real tienen una incógnita Habilidad para "recortar esquinas" cuando lo vean conveniente. Tenga en cuenta que TLS 1.1 y 1.2 reconocen la práctica generalizada de no enviar un close_notify , considerando que dicha falla no invalida la sesión de TLS en su totalidad (la sesión puede reanudarse con otras conexiones) ):
close_notify
This message notifies the recipient that the sender will not send
any more messages on this connection. Note that as of TLS 1.1,
failure to properly close a connection no longer requires that a
session not be resumed. This is a change from TLS 1.0 to conform
with widespread implementation practice.
Consecuencias no son necesariamente malas. El close_notify es necesario para la seguridad cuando el protocolo de la aplicación no es auto-terminado. Por ejemplo, con HTTP-0.9, el cliente sabe que se llegó al final del documento solicitado porque la conexión está cerrada; la falta de un close_notify significa que es posible un ataque de truncamiento (el atacante fuerza maliciosamente a que la conexión TCP se cierre "temprano"). Sin embargo, con HTTP-1.0 y versiones posteriores, los cuerpos de solicitud y respuesta tienen una Longitud de contenido explícita, o utilizan codificación de transferencia "fragmentada", que identifican inequívocamente el final del cuerpo. Para un protocolo de terminación automática como HTTP-1.0, el close_notify no es necesario para la seguridad.
Una situación en la que close_notify es absolutamente necesario es para protocolos que intercambian datos antes y después de la sesión SSL / TLS, en la misma conexión (la STARTTLS método). En ese caso, el cliente y el servidor no pueden enviarse datos de forma confiable a través de la conexión después del cierre de SSL si no marcaron el cierre con los mensajes close_notify .
Para resumir , puede formalmente reaccionar ante la falta de close_notify como un ataque continuo o un fallo de la red, pero si su protocolo de comunicación es auto-terminado , entonces simplemente puedes ignorar la falta de close_notify .