3 Answers
3

Pretty much any active attacks leads to an aborted connection. This includes disrupting the TCP connection as you suggest, or manipulating the payload, triggering a MAC failure, which in turn aborts the connection.

TCP disruptions have happened in practice. While this was against bittorrent, and not SSL protected connections, SSL over TCP can't prevent this kind of attack.

According to independent testing, Comcast injected reset packets into peer-to-peer connections, which effectively caused a certain limited number of outbound connections to immediately terminate. This method of network management was described in the IEEE Communications, May 2000 article "Nonintrusive TCP Connection Admission Control for Bandwidth Management of an Internet Access Link"

It's important to note, that the software using TLS is able to distinguish aborted connections from connections that were closed gracefully, because a gracefully closed connection ends with a TLS "BYE" message, which cannot be faked by an attacker.

DTLS over UDP might be more robust since you can't just disrupt the TCP connection. But of course an attacker can simply swallow all messages preventing the connection from continuing.

SSL 2.0 did not include a verified termination protocol, so any party involved in a SSL 2.0 connection receiving a closure at the TCP level could not reliably determine if the peer really wanted to close the SSL session or not. This was a big issue, especially with HTTP because, in HTTP 1.0, it is allowed not to send a Content-Length header, instead relying on termination of the underlying transport medium to mark the end of the data. Thus, silent truncation was possible.

This has been fixed in SSL 3.0 and later versions (i.e. TLS, because TLS 1.0 is SSL 3.1). A couple of SSL "Alert" messages of type close_notify are exchanged, and these messages, like everything else in the tunnel, benefit from the protection of the cryptography (in particular checked integrity).

If we assume that TLS 1.2 is sound and secure, then there is little that an attacker can do except disrupt the service. He can force a connection close (at the TCP level) but both parties will know that something happened. More insidiously, an attacker with full control of one of the router could slow down the connection, by dropping packets (forcing the TCP implementations to emit then again) and doing other nasty tricks (e.g. forcing the parties to send smaller packets by sending fake ICMP packets which claim that a given packet could not be forwarded because it is too large). The attacker can then send the SSLers chasing geese for a long time, without doing anything as crude and visible as a connection termination. Due to the very flexible nature of TCP, the attacker could drop the bandwidth down to, say, 30 bytes per second (emulating a 300 bauds modem...), which is quite similar to total disruption in practice, except that the computer systems at both ends would still believe the connection to be alive and well, and would not drop it to initiate a new one.

I'm not aware of any method to manipulate an established SSL/TLS session. Such an attack may be successful if an attacker can somehow gain access (or break) the symmetric session key establishment. So, if the SSL/TLS session is long lived or cached and the adversary somehow was able to gain access to the session key, then it's possible for the adversary to manipulate the existing session.

Moving up a few layers, it's usually much easier to install some *ware onto the victim device to intercept/manipulate the traffic at the endpoints. If you go down a few layers, then session termination is fairly trivial, but wouldn't necessarily qualify as session manipulation. However, move down one layer and launching a l1/l2 attack becomes feasible. Basically, MITM at l2 (arp cache poisoning) or l1 (physically bridge) tap into the stream.