OpenSSL documentation says the following: (Source: https://openssl.org/docs/man3.0/man3/SSL_shutdown.html)

It is acceptable for an application to only send its shutdown alert and then close the underlying connection without waiting for the peer's response. This way resources can be saved, as the process can already terminate or serve another connection. This should only be done when it is known that the other side will not send more data, otherwise there is a risk of a truncation attack.

How would this attack work?

In my case, a higher layer closes the connection with no intent to read more data. It seems that a fast close would be the correct way; it presents no danger, and there is no additional benefit of waiting for a peer's close_notify.

If I am correct, it means that the documentation is not precise. It is not about peer sending more data but about a potential need by our side to process this data. If the data can be safely discarded, everything would be fine. And if it is not safe to discard, the bug is in the higher layer, and my TLS layer would be doing the correct thing.

Am I mistaken? Thanks!

  • Define fast close? It is probably wise to have read section 6.1 in RFC 8446 that discusses close_notify alerts and when they're necessary. Feb 20 at 3:31

1 Answer 1


Truncation attacks can always occur when either peer is unable to distinguish a clean, authenticated termination of a connection from an unclean, unauthenticated reset. The way truncation attacks work in general is by just "cutting off" the data stream at some point, hoping that the receiver will process the partial message, treating it like a full message. Whether an application protocol is vulnerable to such an attack depends on many factors, including both the TLS protocol layer and the application layer.

For example, an application protocol that uses length-prefixed (or fixed-length) messages might not be vulnerable to truncation attacks in any case, since a partial message will never successfully fill its message buffer, no matter how the connection was closed. An application that reads messages in a stream-like fashion on the other hand might be vulnerable to truncation attacks, if not implemented correctly.

Regarding the OpenSSL documentation, the important thing to note here is that TLS closures (such as those initiated via SSL_Shutdown) only close the write side of a connection. It is still possible to read data from the peer. Therefore, it is possible that the peer still has data in-flight at the moment the local side closes its connection. Now, if we terminate "uncleanly" there may be a very small window where our side reads this previously-in-flight data, which then gets truncated by our closure of transport protocols. I believe this is (one of the cases) the OpenSSL documentation specifically warns about.

More in general, any kind of unclean shutdown (that the application does not regard as such) may cause truncation attacks on either side, so we can also interpret this as a more general warning: Always be vary when a close didn't run normally. RFC8446 Section 6.1 specifically says:

Either party MAY initiate a close of its write side of the connection by sending a "close_notify" alert. Any data received after a closure alert has been received MUST be ignored. If a transport-level close is received prior to a "close_notify", the receiver cannot know that all the data that was sent has been received.

Each party MUST send a "close_notify" alert before closing its write side of the connection, unless it has already sent some error alert. This does not have any effect on its read side of the connection. Note that this is a change from versions of TLS prior to TLS 1.3 in which implementations were required to react to a "close_notify" by discarding pending writes and sending an immediate "close_notify" alert of their own. That previous requirement could cause truncation in the read side. Both parties need not wait to receive a "close_notify" alert before closing their read side of the connection, though doing so would introduce the possibility of truncation.

The last sentence here "need not wait [...], though doing so would introduce the possibility of truncation." is essentially a repeat (or the origin) of the OpenSSL manpage warning. If truncation is actually a factor is, again, protocol dependent. If your protocol has already (safely) shut down its reader at the time of sending the close alert, a truncation attack on the local side is not possible. If this is done similarly on both sides, the protocol is safe against truncation attacks.

  • The case you described "our side reads this previously-in-flight data" is not possible in my design, but I understand how it could be a cause of concern in general. More importantly, I have learned of a bigger cause of concern that impacts my code, which is that some control messages might be dropped by the TLS layer, such as new session ticket that might come in the end. Am I correct? Thanks!
    – Dragan
    Feb 23 at 12:03
  • Dropping TLS session tickets shouldn't be much of a concern - at worst you can always perform a full handshake if either side is unhappy with the stored state when reconnecting. This costs some performance, but it's unlikely anyway. Not reading a TLS message is in general only problematic if you intend to continue the connection (even if only for a short moment). Since you're shutting down anway, missing stuff like tickets or key updates shouldn't be a problem. To me it sounds like truncation is probably not a big factor to your use case (if at all).
    – Nummer378
    Feb 23 at 16:55

You must log in to answer this question.

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