Those were great replies. Thanks Lev and Geoff. Guess I'll have to put more thought into this. Thanks again, swami
On Wed, 19 Nov 2003, Geoff Thorpe wrote: > On November 19, 2003 07:16 pm, Swaminathan P wrote: > > I have a question anout the use of sequence number as a part of the > > input to the hash function during the MAC calculation. Does that > > security concerns? Would the security aspects of theSSL be affected if > > the sequence number is not used as a part of the input to the hash > > funtion for MAC calculation? > > As Les pointed out, this helps detect replay (or removal) attacks. It also > forces the underlying transport to be reliable and ordered, so that the > SSL/TLS encapsulation in turn presents what appears to be a reliable and > ordered channel to the user of the protocol. For example, it doesn't stop > you trying to run SSL/TLS over something like UDP that does not these > sorts of guarantees, but this aspect of the SSL/TLS protocol will allow > you to detect (in theory) if the packets arrive out of order or don't > turn up at all. It will not *recover* from such problems though, so this > sequence number trick is simply to verify reliability of the transport, > without providing any recovery mechanism if the ordering and reliability > assumptions aren't met. > > But there's two far more fundamental problems with trying to bypass this > ordering issue anyway. (1) the ciphering used to en/decrypt the payloads > of SSL/TLS records (after the initial handshake has agreed parameters) is > typically stateful, so if you get records duplicated, removed, or > out-of-order, then en/decryption will start misreading all subsequent > records as senseless noise. (2) during a handshake or a renegotiation, > the "finished" messages use MAC calculations over *all* the previous > handshake messages *in order*. Note that "all" and "in order" mean that > if you lose reliability during the handshake or renegotiation phase, you > get the SSL/TLS equivalent of a "carrier disconnect" - no amount of > sequencing logic in the application protocol will matter as this > corruption in the handshake protocol will prevent application protocol > data from being exchanged anyway. > > Cheers, > Geoff > > -- > Geoff Thorpe > [EMAIL PROTECTED] > http://www.geoffthorpe.net/ > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
