4

The TLS protocol specifies that a close nofify message should be sent whenever one of the peers wants to close the connection. This prevents a truncation attack that would send a TCP FIN message as if the peer sent it himself.

Therefore, if the connection is closed without receiving the close notify message, it means a malicious third party is messing up with our connection (let's ignore the fact where a legitimate peer would not perform the shutdown properly)

My question is: what should we do in such a situation? Does it mean that the last message received is corrupted and should be discarded? Does the whole session need to be rolled back?

Note that I am thinking about a situation where we are sure that the lack of close notify is malicious as opposed to bad peer implementation. I am also not assuming a specific application protocol.

1
  • 3
    Just going on network traffic I've seen, I think you'll find that far more TLS traffic is improperly terminated (FIN or RST without close_notify) than you think. You can't really ignore legitimate peers because you might find out they look just like your attack scenario.
    – gowenfawr
    Jun 11, 2015 at 18:15

1 Answer 1

6

In practice, many widely deployed HTTPS servers close connections abruptly, without any prior notice, and in particular without the close_notify. They do that because they want to kill connections that have been inactive for too long (say, more than 30 seconds), and they want to do it even if the connection was inactive because the client is gone (e.g. crashed, or moved out of range of the WiFi access point, or any other similar situation) and will not actually acknowledge the close_notify.

It would be technologically feasible for a server to send a close_notify even to a dead client, and still clean up resources properly, but many server designers find it easier to simply not send the close_notify (this allows keeping the SSL engine and the socket management separate). This is in contradiction with the TLS standard, but we know that real-world developers have an uncanny ability to "cut corners" when they see fit. Note that TLS 1.1 and 1.2 acknowledge the widespread practice of not sending a close_notify, by considering that such a failure does not invalidate the TLS session as a whole (the session may thus be resumed over other connections):

   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.

Consequences are not necessarily bad. The close_notify is necessary for security when the application protocol is not self-terminated. For instance, with HTTP-0.9, the client knows that the end of the requested document is reached because the connection is closed; lack of a close_notify means that a truncation attack is possible (the attacker maliciously forces a TCP connection close "early"). However, with HTTP-1.0 and later versions, request and response bodies have an explicit Content-Length, or use "chunked" transfer encoding, both of which unambiguously identifying the end of the body. For a self-terminated protocol like HTTP-1.0, the close_notify is not needed for security.

A situation where close_notify is absolutely needed is for protocols that exchange data before and after the SSL/TLS session, over the same connection (the STARTTLS method). In that case, client and server cannot reliably send data to each other over the connection after the SSL closure if they did not mark the closure with close_notify messages.

To sum up, you may formally react to a lack of close_notify as an ongoing attack or a network failure, but if your communication protocol is self-terminated, then you may simply ignore the lack of close_notify.

2
  • Thank you, but that doesn't really answer my question. I am assuming that a truncation attack is indeed happening. What to do when we detect it?
    – Jacques
    Jun 11, 2015 at 19:31
  • 1
    The short summary: if your protocol is self-terminated (as it should, for other reasons) then the attack is harmless, and often is not an attack but a mere mundane network failure. If your protocol is NOT self-terminated, then the attack is serious and you should react to it the same way you react to other attacks: received data is truncated, thus shall be discarded. However, this means that you will raise alarms for simple transient network failures, and soon your staff will simply ignore alarms (and then situation will be worse). Jun 11, 2015 at 19:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .