Dear,
I have 2 questions about this sequence number in TLS:

1)What is the value of finished's sequence number? It is zero?
2) Is there any command line with OpenSSLto have the MAC?

Thank you,
-Bdr

Swaminathan P wrote:
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]


  

Reply via email to