Re: [TLS] TLS Digest, Vol 65, Issue 69

[Yoav Nir <[e-mail]>]

On Dec 17, 2009, at 8:26 AM, Ravi Ganesan wrote:


> Ravi Ganesan wrote:
>> Anyone who reads the  the first documents that came out on this issue
>> (http://www.phonefactor.com/sslgapdocs/Renegotiating_TLS.pdf and
>> http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html)
>> would be left with very different perceptions of the magnitude of the
>> impact. This is not unnatural in such matters; great minds usually think
>> differently...., but after all this discussion perhaps a blurb in the
>> draft with advice on who should immediately patch might be useful.
>
> In short, everyone* needs to patch and disable compatible/insecure mode
> as soon as is practical.
>
> *Except those who can prove that their endpoint cannot renegotiate and
> will never be willing to talk to a server that can possibly renegotiate.

No, even those.

If any server does not patch, it will soon fail to be interoperable with
clients that require patched servers.

I see. Sorry, I missed that in all the discussion. Sticking to the specific case of when the Client is a browser and the Server is a web-server do the browser vendors plan to "require" patched servers?

"require"? My bet is, not anytime soon.

I was assuming (hoping?) that a patched browser can deal with an unpatched server gracefully without failing. I have selfish reasons for asking as I run a EV-SSL protected site, with no control over when my hosting company will upgrade, but I suspect this would be the single most impacted use case. Cheers, Ravi

My guess is that when patched servers have become common enough that it's weird to have an unpatched server, browser vendors will make us go through the "Continue to this website (not recommended)"/"I understand the risks"/"Safari can't verify..."/"You need to approve or reject" ritual that they make us go through for certificate errors.