![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
David-Sarah Hopwood wrote: > Nelson B Bolyard wrote: >> On 2009-11-19 11:20 PST, David-Sarah Hopwood wrote: >>> David-Sarah Hopwood wrote: >>>> Nasko Oskov wrote: >>>>> If the MiTM sends a client hello to the server that has no extension, >>>>> then the server has no way to drop the connection. This will require >>>>> a strict server to prevent the attack and strict server config will >>>>> not be reality for a long time. What am I missing? >>>> That, in the RI approach, strict server config is essential from the >>>> start. >>> Point of clarification: "strict server" here means that the server does >>> not accept *renegotiations* with an unpatched client. It still accepts >>> initial handshakes. >> If that is a "strict server", then what is a "lenient server"? >> Is it a vulnerable server? > > A server that does accept initial handshakes with an unpatched client > (which obviously makes it vulnerable in that case). Gack, sorry, typo. A lenient server is a server that does accept *renegotiating* handshakes with an unpatched client (which obviously makes it vulnerable in that case). Both lenient and strict servers accept initial handshakes from any client. I don't think there is ever a reason to reject initial handshakes where no client certificate is used. There might be a reason to reject initial handshakes where a client cert is used, in order to prevent the variant of an attack where the client sees the renegotiation, and is unpatched. > However, a lenient > server, unlike an unpatched server, will detect an attack on connections > with a patched client. That is, on any connection with a patched client. > I believe this is not enough to consider the server to have been "fixed", > and I think it's a bad idea to end up with a subset of servers that > appear to be patched, but are still vulnerable on some connections. -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
Attachment:
signature.asc
Description: OpenPGP digital signature