Re: [TLS] Third Option?

[Yoav Nir <[e-mail]>]

On Dec 17, 2009, at 1:36 AM, Ravi Ganesan wrote:

On Wed, Dec 16, 2009 at 2:43 PM, Marsh Ray <[e-mail]<mailto:[e-mail]>> wrote:
Ravi Ganesan wrote:
>
> A third option is to leave renegotiation in, but create an advisory that
> explains the semantics;

What do you (as a vendor) tell your customers when they know they are
vulnerable and call you for a fix?


Have TLS 1.3 code ready and tell them to upgrade to it.  Asking customers to move to newer release in order to fix security problems is something the market understands. (did not say 'likes').

Except that the browsers they have don't support TLS 1.3 yet. If the TLS 1.3 spec came out today, it would be years (8? 10?) before you can assume that everyone has a supporting browser.


However, if you are correct in your impact analysis in your original paper, then an emergency patch is the appropriate response. I am not sure I know enough to agree with your impact analysis, but either way, good job done by your team and Martin on this discovery -- it will make TLS 1.3 better.

One stat that might allow us  to ascertain immediate impact: If I am a web site who strictly ONLY uses server side SSL (with client auth being handled by passwords, etc.),  And, I have ability to turn of renego. Will that do the trick? If so what portion of SSL users fall into this use-case?

Yes. Disabling renegotiation on the server side solves the problem, and probably over 95% of users fall into this use case.  However, even for them, there are two problems with this solution:
 - until very recently there was no "disable renegotiation" switch on the various servers.  OpenSSL added this to 0.9.8l just last month. Upgrading to OpenSSL 0.9.8l means getting all the code changes between the release you're using and the new OpenSSL version. This might cause you other problems.
- There's no signaling that renegotiations are disabled. The browser cannot show me that I'm talking to a secured server.