To complete @raz' answer, a few points:
OpenSSL, and thus implementations based on OpenSSL (clients and server), tend to no longer send
close_notify messages; they just drop the connection. The main reason is that in existing Web servers and clients, connections are managed in a pool that closes them after some inactivity delay; that pool manages low-level sockets and has no notion of what SSL could be; thus, the SSL layer has no way to send (or wait for) an explicit
One underlying reason for this design is to avoid keeping resources unduly. From the point of view of a server, an inactive client may be a dead client -- possibly, the client computer crashed or shut down more or less cleanly, or its network access just dropped. Thus, there may be nobody to receive the
close_notify. Normally, TCP connections are buffered, so the server code could send the
close_notify and close the connection immediately, without having to wait for an ACK from the client (ACK which will never come, the client having died). However, client death may occur at any time, including during the sending of the previous answer from the server, so the TCP buffer may be full at that time. Thus, the sending of the
close_notify might stall for a long time, until the TCP layer decides that the connection is really dead (this may take hours).
By simply closing sockets directly, after some fixed inactivity delay, regardless of the connection logical state at that point (SSL or not; sending an answer or waiting for the next request), servers ensure that they avoid blocking resources for the benefice of dead clients.
The main "truncation attack", at the HTTPS level, is related to HTTP 0.9. In HTTP 0.9, each request uses a new connection, and the server sends back the answer with no explicit data termination; when the server has finished sending the data, it closes the underlying socket. The client thus knows that it got all the data when the socket is closed.
With HTTP 0.9, lack of a
close_notify implies that attackers could truncated the answer (by forcing a TCP-level close) and the client would not know it. This was accounted as one of the main weaknesses of SSL 2.0.
However, opening a new connection for each request is greatly inefficient, so from HTTP 1.0 onwards, clients and server reuse connections for several requests and responses. This, in turn, requires the HTTP protocol to be self-terminated: inspection of the exchanged bytes alone must be sufficient to decide whether the end of a request or answer was reached, without relying on a "closure" event from the transport medium. Basically, clients and servers use explicit
Content-Length headers, or (for data streaming) use the "chunked transfer coding". When the application protocol that goes within the SSL/TLS tunnel is self-terminated, the
close_notify is redundant, and can be dispensed with. Which is exactly what happens in modern HTTPS. No modern server ever uses HTTP 0.9 any more; all their responses are self-terminated; so they can afford (from a security point of view) not to send a
The truncation attack that @raz talks about is one level higher: the client sends an HTTP request for some "logout" action, but does not wait for the corresponding answer (an HTTP answer, not a
close_notify). Presence or lack of a
close_notify does not change anything here; the weakness is an impatient user.
SSL/TLS session reuse is actually larger than a mere resumption. Originally, SSL was designed under the idea that the client opened one connection to the server, simply opening a new one if the previous one was closed.
Web browser no longer do that. Instead, they open several connections to the server, mainly so that they can send requests in parallel, for a better user experience. The HTTP-1.0 reference says that:
Clients that use persistent connections SHOULD limit the number of
simultaneous connections that they maintain to a given server. A
single-user client SHOULD NOT maintain more than 2 connections with
any server or proxy.
However, practice is, as always, a bit different (some browsers, though, apply different limitations on the number of simultaneous connections depending on whether the connections use SSL or not).
For all these connections, a typical browser will do a complete handshake with one connection, then "resume" that session for other connections, even though the "session" is still alive and kicking on the first connection. Therefore, sessions can be resumed before having been stopped. The provision in TLS 1.0, quoted by @raz, merely extends that idea in that it defines that sessions can be resumed regardless of what happened or still happens with the same session on other connections. In effect, session resumption is no longer about resuming, but rather reusing the session parameters (i.e. the negotiated shared secret key).
Summary: SSL/TLS formally provides cryptographically-protected closure: when a connection is closed, both client and server have guarantees that the closure is genuine, and not injected by an interloping attacker. Existing practice deviates from that theory, and implementations no longer offer that guarantee.
This is not a problem for HTTPS Web servers because such servers enforce the use of a self-terminated application protocol (HTTP 1.0+ with explicit chunk or content lengths) that does not need cryptographic protection of closures.
In full generality, not sending a
close_notify is a weakening of the protocol, which might be leveraged if (and only if) the underlying protocol is not self-terminated. Fortunately, non-self-terminated protocols are exceedingly rare, and could be described as "poorly designed" (if only because they don't allow connection reuse), so this weakening is not a big issue in practice (for the time being...).