João 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. You are completely misunderstanding what this is saying. What this is saying is that TCP will not duplicate or lose data. It will either break the stream entirely or replicate the stream of data accurately at the other side. It says *nothing* whatsoever about the ability to determine what the other end has received. In fact, the application on the other end can be completely frozen and incapable of receiving anything and TCP will happilly send ACKs to the other side. That's because TCP ACKs are TCP protocol level acknowledgements and are not intended to have any meaning at other layers. TCP specifically does *not* communicate ACKs up to the application because these ACKs do *not* indicate that higher levels on the other end have received the data. > 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." Of course. > 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. Neither SSL nor TCP guarantee that data will get through. > 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... Because you misunderstand the role of TCP acknowledgements, you misunderstand the effects of tampering with them. Consider: application <-> TCP <-> network <-> TCP <-> application The acknowledgements are generated in, and processed by, the parts labeled 'TCP'. The data is received at the parts labeled 'application'. So TCP acknowledgements don't *ever* tell you whether or not the *application* got the data. So no attacker can, by spoofing TCP acknowledgements, convince one application that another application got any data because TCP acknowledgements never do that. If that's not good enough for you, here's the basic argument why SSL is invulnerable to all such MITM attacks: 1) Either the MITM disrupts the data or does not tamper with the data. 2) If the MITM does not tamper with the data, he cannot understand it and does no harm. So we're okay. 3) If the MITM disrupts the data, the data won't get through and the SSL connection will fail to deliver data or break. However, the MITM cannot decode any data nor can he inject any data. So at best, he can break the SSL connection, but he could do that by cutting the cord. Or question is, "can a MITM who can only see the TCP packets and inject his own TCP packets but not stop legitimate packets from getting through break the SSL connection", the answer is yes, he can trivially do so by spoofing TCP RSTs. If your question is, can he decrypt or modify the data undetected? The answer is no, because SSL has checksums and uses cryptography properly. There is no attack where you make the other application think it got data it did not because there is no such mechanism in SSL. SSL has no way to say "the other application got this data" because SSL has no way to know anyway. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
