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, they have otherwise no chance of noticing it,... or telling the server admins. And if a user nevertheless want's to use such a server, he can still disable it ... but manually. The fact that secure servers usually block insecure clients, doesn't help here at all. > It will take a lot longer until security.ssl.require_safe_negotiation > can be switched on by default. Look at how long it took for SSLv2 to > disappear. It was more or less the same problem,.. now we ship a configuration which is insecure by default, and gives people not even a chance of noticing this, especially as everybody thinks it is solved in the meantime. Having no service at all is here much better than having it but insecure,... because that's just was SSL/TLS is for. Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
