Re: [TLS] TLS or HTTP issue?

[Dean Anderson <[e-mail]>]

On Fri, 6 Nov 2009, Florian Weimer wrote:

> * Nikos Mavrogiannopoulos:
> 
> > I'll become a bit pedantic and note here that this isn't really a TLS
> > issue.

Its a TLS issue.  However I don't think we should worry too much about
https.  I've used client certificates on some websites, and let me tell
you, its really a non-starter to use renegotation because most
webservers have a 250k buffer (On apache this is a compile-time
constant) for renegotiation, which isn't big enough to complete a lot of
http transactions, anyway. As a result, one usually winds up breaking up
websites into two or more sites, with one site completely client
certificate controlled so that no renegotation necessary on that site,
and the rest of the content is on another site that also needs no
renegotiation.

> Theoretically, this attack can be detected by the server,

Theoretically, I think not. The problem (inherent to every MITM attack)
is that there is some plaintext the MITM can change or otherwise use.  
The solution is the same in every case: Eliminate the plaintext or
encrypt it in a (e.g public key) cipher so that the MITM can't alter or
read it.

That's what should happen here. We should not worry about whether this
is hard to program or not.  It simply shouldn't be plaintext.  I don't
think it ought to be too difficult to program, as the client and server
have already public exchanged keys that could be used to encrypt the
renegotiation.  

Of course, https is still as screwed as before, but like I said above,
it is of no consequence as there are already problems with renegotation
that cause renegotiation to be avoided. So we need not worry about
https.  But renegotiation should be made to work in TLS, as other
protocols that rely on TLS don't have the large, essentially unlimited
transaction size problems that https has.

		--Dean


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 256 5494