4

I know this question looks very silly, but, it has been bothering me for a while and I am unable to come up with an answer by myself. So, here it goes..

Packets in the TLS protocol consist of a 5 byte header followed by data which is encrypted once the handshake is done. The 5 byte header is always transmitted in the clear and it also contains a 2 byte length field.

Now, the MiTM attacker can just modify the length field alone in the header, such, that receiving party ends up waiting for a large amount of data, even after receiving the actual amount of bytes originally sent by the peer side. For Ex: Let's say peer side has sent a packet of 20 bytes, and the MiTM attacker just modifies length field of the header to make it 65535 bytes. Now, if no other data is sent by the peer, then the receiving side will wait indefinitely to receive the 65515 bytes (65535 - 20) which was never sent in the first place.

The TLS includes the header in MAC calculation, so any tampering with the header will result in a failure and effective connection closure. But, how is the case of blocking on socket to receive data resolved?

The receiver can avoid it by using a non-blocking sockets with select(again select should have a timeout) or using timeout with sockets. But, how about the case of blocking sockets? Is there anyway at all in which we can avoid the receiving side blocking on the socket?

Jay
  • 525
  • 6
  • 15

1 Answers1

4

An attacker who can modify TLS record headers can actually block packets altogether, thus making the receiver wait "indefinitely". There's nothing that the TLS protocol can do to prevent that.

TLS implementations can use time-out strategies, i.e. if no activity has been received from the peer for some time (e.g. 15 seconds) then the connection can be dropped automatically. This is needed anyway to handle the case of clients crashing: when a machine crashes, it ceases to send packets, but it won't tell that it can no longer send packet, since it is crashed.

It is a generic property of TLS. TLS does not try to recover from a transport failure; it just tries to reliably detect alterations. Attackers can always cut the wire or postpone traffic for arbitrary amount of times. For that matter, the TLS records are considered "transport" just like the underlying TCP connection. The MAC used in records is where detection occurs, and it covers the record payloads only.

Tom Leek
  • 168,808
  • 28
  • 337
  • 475
  • About the part "it covers the record payloads only", I think this affirmation needs a bit of clarification. As far as I understand from RFC 5246, section 6.2.3.1, "the MAC is generated as `MAC(MAC_write_key, seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment)`", so it does cover all fields and not just the payload itself. – Lucio Paiva Apr 09 '22 at 10:26