SSL and TCP

[pvs...@yahoo.com]

Hello all,

I was reading the paper "Analysis of the IPSec Key Exchange Standard"
by Radia Perlman and Charlie Kaufman.
http://sec.femto.org/wetice-2001/papers/radia-paper.pdf
In Section 2.2 they have written the following:

"There is a problem in operating above TCP. Since TCP will not be
participating in the cryptography, it will have no way of noticing if
malicious data is inserted into the packet stream. TCP will acknowledge
such data and send it up to SSL, which will discard it because the
integrity check will indicate the data is bogus, but there is no way
for SSL to tell TCP to accept the real data at this point. When the
real data arrives, it will look to TCP like duplicate data, since it
will have the same sequence numbers as the bogus data, so TCP will
discard it. So in theory, IPSec's approach of cryptographically
protecting each packet independently is a better approach. "

When TCP has already acknowledged the data which is malicious according
to SSL, how will a retransmission by SSL cause the remote TCP to use
the same sequence number and cause the first end point's TCP to discard
it?

Thanks and Regards,
Prashant

[Rick Jones]

If the data is resent by SSL, TCP will treat it as new data.

I suspect the paragraph above is referring to the first send of the
"real" data by SSL - think of it as a race between SSL and the
malicious interloper. If the interloper's data gets there first,
SSL's first data will be ignored. If SSL's data gets there first, the
interloper's data will be ignored.

rick j ones
--
Wisdom Teeth are impacted, people are affected by the effects of events.
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

[VivekRajan]

When TCP has already acknowledged the data which is malicious according

to SSL, how will a retransmission by SSL cause the remote TCP to use
the same sequence number and cause the first end point's TCP to discard

it?

1) SSL (TLS) does not retransmit, it assumes TCP provides a reliable
channel.

2) Once a TCP advances its sequence/ack numbers it cannot roll them
back. In other words, you cant replace invalid data if it has already
been delivered to the application.

3) If invalid data gets through TCP and subsequently fails the crypto
checks, it means your SSL connection has been compromised. There is
someone executing a man-in-the middle attack like TCP session hijack.

What Radia is claiming is that SSL is vulnerable to the TCP session
hijack attack. Any protocols built on top of TCP are also vulnerable to
this.

Vivek Rajan

[pvs...@yahoo.com]

Hi,
Thanks for the explanation. The paragraph seems to be clear in the
context of man in the middle
or as Rick mentioned about the attacker sending malicious data with the
correct TCP sequence number before the original data arrives at the
receiver.

Thanks and Regards,
Prashant