On 01/29/2011 01:12 PM, Christoph Anton Mitterer wrote: > On Sat, 2011-01-29 at 18:47 +0100, Stefan Fritsch wrote: >> This has to be balanced between compatibility and security. Currently >> less than 50% of the servers on the internet are patched. So it is >> sensible to not deny renegotiation for unpatched servers. >> >> Patched servers usually won't allow insecure renegotiation, anyway. >> There are also many servers that don't allow renegotiation at all. So >> the problem is mostly about the browser knowing if the remote server >> is secure. > > The only correct solution here is to fail then,... > If users have such servers,
When did debian servers using OpenSSL become compliant with secure renegotiation? http://www.debian.org/security/2011/dsa-2141 Looks like about three weeks ago. Not a huge amount of time. There are probably other online update systems that are even less up-to-date. Consider also the huge number of embedded devices (e.g. printer and home router configuration webapps) that are almost certainly not updated. Should users of iceweasel be prevented from accessing them? > they have otherwise no chance of noticing > it,... or telling the server admins. The user has a chance to notice it if they watch their error console logs, which produce a message: foo.example.org : server does not support RFC 5746, see CVE-2009-3555 I would be happy to see this warning get much more prominence (e.g. like one of the little ephemeral "your downloads have completed"), but simply blocking users out of half of the https web servers on the 'net will make people switch to other browsers (or other operating systems) in order to keep connecting to the sites that they use. (either that, or they will revert to plain HTTP on sites that still allow it, because it "doesn't lock them out"). This is a win? This is a shitty set of tradeoffs, but i don't think we can afford to sacrifice the usability of the browser at this point without a more concerted effort to ensure we're not locking users out of sites that are (for whatever reason) still not compliant with RFC 5746. i sympathize with the goal of wanting it to allow only secure access; but i don't think the level of threat (plaintext prefix injection) and the weak deployment of compliant servers warrants a switch in the defaults right now :( Patches to make the bugginess/vulnerability of any given server more visible to the user (and to the server operator) would be great, of course. --dkg
signature.asc
Description: OpenPGP digital signature
