Re: [TLS] TLS or HTTP issue?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] TLS or HTTP issue?
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
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.