Brian Smith wrote: > > There's no evidence that the presence or absence of an alert when a > connection is closed makes any positive difference in the security of any > non-secure fallback mechanism. Keep in mind that the alerts during the > handshake are NOT authenticated, and the TLS threat models thus assumes > that the attacker can remove or alter them.
Alerts can help troubleshooting/debugging, in particular when one only has access to logs/traces of one of the communication peers. Alerts are not authenticated, and whenever they're the last message on a connection, could get lost on socket closure (killed in a tcp socket when pipe is full and lingering not enabled), or could get stripped by an attacker. How many TLS implementation remove a session from the session cache if the session ends without close-notify? The original idea wasn't really well thought-out, because implementations may start TLS session "forking" (storing sessions in cache and proposing their resumption on parallel network connections) immedately when the TLS handshake has completed (and before any app-level request & response has completed, i.e. long before a close-notify alert will be exchanged. There are TLS implementations that use a transport-free programming API, which means that the decision to send a fatal alert over the transport is not a decision of the TLS implementation, but of the application caller on top. And that application caller may not bother with processing any "transport requests" that accompany a fatal API error code at all. Microsoft' TLS implementation (SChannel) is an example of a transport-less implementation, and neither MSIE nor IIS send fatal TLS alerts over the wire before they close the network connection after a TLS handshake failure. (I don't have any Windows 8.x or 10 machines, so I don't know whether this was ever changed). You'll have to dig out the TLS alert number from the windows system event log on the machine where it happened, which is often not an option when the remote peer from a different service provider hangs up half way through the TLS handshake. Easier troubleshooting is IMO a sufficient rationale to justify existence of the alert mechanism and a "SHOULD send the alert before closing the network connection". A "MUST send fatal alert" requirement, however, would be silly (and will be void in face of rfc2119 section 6 anyway). What would be the semantics of such a requirement anyway? If one of the communication peers closes the network connection prior to completion of the TLS handshake, then the result is a 100% interoperability failure. How is a "MUST send alert" supposed to affect that outcome when the server does not send one? Is it a 120% interop failure then? -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
