11

I understand that SSL/TLS is built on top of TCP. That is after a TCP connection is established, an SSL handshake can be started, when it is completed, all communication will be encrypted and authenticated. To close the connection a specific alert is used.

I would like to understand whether an attacker is able to terminate a TCP connection if SSL/TLS has been used to protect the data used in a TCP Segment

I have found this...

If an attacker tries to terminate the connection by finishing the TCP connection (injecting a FIN packet), the communicating parties will know the connection is improperly terminated. The connection cannot however be terminated, only interrupted.

But I would like to know how the communicating parties would know the connection is improperly terminated and why it is only interrupted.

Furthermore, is the injection of a TCP FIN message the same as injecting a TCP RST message to tear down the connection?

Any thoughts?

ellefc
  • 509
  • 2
  • 7
  • 14
  • 2
    Though not imprescindible, it would be good to know where you "found" that? – clem steredenn Apr 13 '16 at 05:40
  • It seems to come from [this answer](http://security.stackexchange.com/a/20833) from [Luc](http://security.stackexchange.com/users/10863/luc). Last paragraph of **High-level description of the protocol**. – Yuriko Apr 28 '16 at 06:24
  • Using SSL Alert protocol close_notify packet and then deleting packets afterword will cause termination – AZ_ Feb 08 '18 at 15:27
  • @AZ_ only if you can forge the encryption and authentication (MAC or AEAD), which except for the old obsolete 'export' and single-DES suites should be infeasible – dave_thompson_085 May 23 '18 at 03:15

2 Answers2

2

This is entirely doable, with the caveat being that you need to know the correct sequence number required by the target tcp stack. (so to be able to do it for all connections to a server, you have to be either on the server itself or a gateway to that server).

Note: the farther you are from the target stack, the more likely it is that you'll have timing issues with the injection. (presuming it's a packet injection and not a full mitm)

I also know from experience that such intercepts are swiftly broken with a small security update to the target stack :(

Rst and fin will be relatively closely guarded, it may be worth looking at just setting the tcp window size to zero instead? (just a thought, been a long time [a decade now!] since I played with this stuff)

..but I would like to know HOW the communicating parties would know the connection is improperly terminated and why it is only interrupted.

The whole point of tcp it to provide reliable connections, if you kill the connection then the stack on each side knows. It's only interrupted because when the connection dies most systems will retry the connection, usually without even telling the user.

Nathan
  • 822
  • 6
  • 12
  • By injecting a packet with correct sequence number but faulty data you can cause DoS attack, because TCP will accept the packet as the sequence number is correct but then SSL will discard it because TCP seq# is part of MAC and when the original packet will arrive now TCP will discard it because it has already sent this packet to upper layer. – AZ_ Feb 08 '18 at 15:31
1

My initial response is below ("No…") in a blockquote, but I need to correct this, because I think my response is wrong. TCP itself does not ensure immunity from replay and/or man-in-the-middle attacks. In fact, this kind of interruption is commonly known as a TCP reset attack. The problem is that TCP has no built-in authentication of messages and bare TCP cannot guarantee the authenticity or veracity of packets – to achieve that, one needs to rely on Transport Layer Security (TLS) in HTTPS. If an application is able to detect an out of order packet or an illegitimate FIN, this is auxiliary service and it is unspecified by the TCP standard. Now below is my initial incorrect assessment:

No, an attacker cannot successfully terminate a TCP connection with the injection of a `FIN` packet, since TCP is a mutually contingent protocol that requires both parties agree (i.e., one side initiates a state change by sending declaration of intent, then it waits to receive acknowledgment of that intent, and then it will transact the state change) to the transaction for that transaction to be executed. This corresponds to the answer given in Brent Baccala's (editor) *Connected: An Internet Encyclopedia,* Third Edition where we find the following:
Case 2: TCP receives a FIN from the network If an unsolicited FIN arrives from the network, the receiving TCP can ACK it and tell the user that the connection is closing. The user will respond with a CLOSE, upon which the TCP can send a FIN to the other TCP after sending any remaining data. The TCP then waits until its own FIN is acknowledged whereupon it deletes the connection. If an ACK is not forthcoming, after the user timeout the connection is aborted and the user is told.
[Connected: An Internet Encyclopedia TCP Connection Close][5] So even if the packet sequence number is correct, an unexpected `FIN` does not just end the communications between the two computers according to the TCP protocol description. Let's not forget: The receiver will not just issue a response to the sender acknowledging the `FIN`, but will actually receive two conflicting packets with the same sequence number – and unless the receiver is in a point of anticipating the `FIN`, it will be dropped and communication will either continue or restart at the last state agreed upon by both terminals.
Mavaddat Javid
  • 288
  • 1
  • 7