TCP allows for hijacking -- but the fact that the SSL/TLS layer uses secret, ever-changing HMACs means that an attacker cannot pass any data to the hijacked session without it being detected and a protocol error resulting. (Much less the encryption key for all but NULL ciphers.)
TCP guarantees delivery only insofar as packets can go back and forth. If an ACK is not received, the TCP implementation will try to resend the packet that wasn't ACKed. After a while, it will time out. Try unplugging your router from the cable/DSL modem while you're connected, sending data. Watch the packet stream under tcpdump or wireshark. After the physical connection is severed, data can't get through -- period -- and thus the "guarantee" that you're referring to is broken. (TCP is a layer 4 protocol, which relies on IP or IPv6 at layer 3, which relies on PPP or Ethernet at layer 2, which relies on a serial line/phone line/ethernet cable connection at layer 1. If layer 1 is broken, all services above it which rely on it are broken as well.) Note: SSL/TLS can operate perfectly well over a bidirectional serial connection, without relying on TCP or IP packetization. All it requires is a reliable, sequenced, bidirectional data stream of any kind. It still maintains its defenses against Mallory (malicious router) and Eve (eavesdropping router) in that configuration, even if there's a vampire tap installed on the serial line. -Kyle H On Sun, May 17, 2009 at 2:59 PM, João Távora <joaotav...@gmail.com> wrote: > >> TCP does not provide "delivery assurance". If the application needs to >> know >> the data got through, it must use application-level ackwowledgements. SSL >> does not change this and provides the same set of guarantees and >> assurances >> TCP does. > > I'm sorry to disagree but TCP, unlike UDP, does provide "reliable data > transfer". It does allow hijacking. I'll take from wikipedia to try to > explain better > > http://en.wikipedia.org/wiki/Transmission_Control_Protocol > > "TCP is a reliable stream delivery service that guarantees delivery of a > data stream sent from one host to another without duplication or losing > data. Since packet transfer is not reliable, a technique known as positive > acknowledgment with retransmission is used to guarantee reliability of > packet transfers. This fundamental technique requires the receiver to > respond with an acknowledgment message as it receives the data. The sender > keeps a record of each packet it sends, and waits for acknowledgment before > sending the next packet. The sender also keeps a timer from when the packet > was sent, and retransmits a packet if the timer expires. The timer is needed > in case a packet gets lost or corrupted. > > [...] > > An attacker who is able to eavesdrop a TCP session and redirect packets can > hijack a TCP connection. To do so, the attacker learns the sequence number > from the ongoing communication and forges a false packet that looks like the > next packet in the stream. Such a simple hijack can result in one packet > being erroneously accepted at one end." > > I guess this can be done with ACKs as well. I'm almost absolutely sure SSL > can detect these hijacks and signal an alert, but I wanted to be sure. > > Maybe I'll try some ASCII-art tomorrow or get an experimental answer by > capturing an SSL session and seeing exactly what goes to and from. I suspect > the "sequence number" field of SSL record segments mentioned in the RFC > might be what I'm looking for... > > Thanks anyway! > João > > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-us...@openssl.org > Automated List Manager majord...@openssl.org > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
