Re: [TLS] TLSrenego - current summary of semantics and possibilities

[Martin Rex <[e-mail]>]

Michael D'Errico wrote:
> 
> > What you're asking for is to discontinue talking to the entire installed
> > base of SSL&TLS implementations.  i.e. clients should only talk to
> > updated servers (which means they must be updated clients).
> 
> I'm not asking for that.  People seem confused about who sees the
> renegotiation.  The client *does not* see a renegotiation in the MITM
> attack.  It simply connects once giving its credentials, and the attack
> is complete.

It doesn't see one in the scenarios described by Marsh.

The client will see an renegotiation in the scenario I posted to this list.

> 
> > HUH?  The Renegotiation_Info is required for cryptographic binding
> > during the renegotiation handshake.  Without it, there is zero protection.
> 
>  From just the client's perspective, all it needs is for its initial
> handshake to have sent and received an empty renegotiation info extension.
> Once that handshake completes, it knows that there is no MITM.  From then
> on, it doesn't need secure renegotiation; it can only be talking to the
> same server.

So if I mount the attack I described on your client, and use the
empty TLS extension in the sess1 handshake between your client and
my MITM, then your client is going to renegotiate blindly with the
server to which I'm connecting it?  Not good.  Your fix is incomplete.



Here's a mean out-of-context quote from RFC-5246:    :-D

   D.4.  Implementation Pitfalls

      [...]

   TLS protocol issues:

      [...]

   -  Do you support renegotiation, both client and server initiated?


-Martin