Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3

["Rob P Williams" <[e-mail]>]

Marsh Ray wrote:

> Rob P Williams wrote:
> > By changing the way the Finished message is calculated - you can
make
> > SSLv3 safer.
> 
> I think this is a good idea for SSLv3. (the proposed extension is
better
> for TLS)
> 
> > Approach:
> > 
> >     For initial handshakes - keep the calculation the same.
> > 
> >     For subsequent handshakes - 
> >         append extra information to 'handshake_messages' before
being
> > hashed.
> >         This could be as simple as a counter. 
> >         This could be the finished data from the previous handshake.
> 
> It has to be something that MITM cannot prep the client or server into
> matching. A 'renegotiating' bit is not sufficient, even a counter may
> not be (M just renegotiates that same number of times before
splicing).

The counter option would mitigate this attack, the client is at
'initial', the server is at one when the splice is attempted. The hashes
in the Finished message will be different.

An attacker would require both ends to handshake the same number of
times (and be in sync) to make the splice possible. 

A client that would handshake with the attacker (to match the counter)
would be susceptible to a proxy...


Adding the previous finished data to the hash offers similar features to
the TLS extension proposal. Instead of transmitting the channel binding
explicitly, they are being compressed by MD5 and SHA1.


> Is it possible to define this in terms of what already exists? E.g.
> simply "don't reset the handshake MAC state for renegotiations" ?

I feel that keeping the digests themselves (the bytes, or the finished
data, or the counter), and not the state of the SHA1 and MD5 (which may
never be used) is less resource intensive.

However, keeping them running would match the 'ALL' handshake messages
point above...


> > 	I've attempted to draw a table of what would happen when
> > renegotiating;
> > 
> > 	OC = old client
> > 	NC = new client
> > 	OS = old server
> > 	NS = new server
> > 
> > 
> >             OS   | NS
> >            ------+-----
> >       OC  |  .   | fail
> >       NC  | fail | good
> > 
> > 
> > OC-NS failure - is useful - 
> >     it shows the attack being mitigated.
> > NC-OS failure - is ALSO useful.
> >     By attempting to renegotiate - you can verify if you are talking
to
> > an OS or NS.
> 
> Well, if the remote endpoint allows you to initiate a renegotiation.
MS
> IIS for example responds with a TCP RST, other implementations may be
> less direct.

Good point! 

An attacker could just hang up on a (current or new) client to make them
think they are using a renegotiation proof IIS instance... 

Only seeing a correct renegotiation with a new server would verify that
you are talking to a new server.



--
rob | Software Developer
Certicom Corp. | A susbidiary of Research In Motion Limited

main | [phone]
direct | [phone]

[e-mail]
www.certicom.com





































---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.