![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Stefan Santesson wrote: > On 09-11-20 5:24 AM, "Michael D'Errico" <mike-list at pobox.com> wrote: > >> Some servers apparently cannot function without renegotiation. >> They will need to continue providing service to unpatched >> clients for some amount of time and thus remain vulnerable. > > I fully agree, > > However, just because a server accepts renegotiation with an unpatched > client, does not necessarily mean that the service provided over TLS is > vulnerable. > > One example is if authentication is performed with proper channel binding in > a layer above TLS and the service is provided under that security context. I'm skeptical. How can "proper channel binding" be done correctly in a layer above TLS, if the TLS library merges renegotiated sessions? Since the session merging will result in the client and server's state at the higher layer(s) being out of sync, nothing can be assumed about the correct functioning of those layers. > I second that lenient server - unpatched client must work while ensuring > that lenient server - lenient client can't be abused using downgrade > attacks. Obviously *if* lenient servers are supported, then we need to make sure that lenient patched server - lenient patched client connections are secure. But I remain unconvinced that lenient servers need to be supported. -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
Attachment:
signature.asc
Description: OpenPGP digital signature