Re: [TLS] Proposal for hybrid solution using most of the ideas
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [TLS] Proposal for hybrid solution using most of the ideas



On 2009-11-18 21:29 PST, Steve Dispensa wrote:
> On 11/18/09 10:10 PM, "David-Sarah Hopwood" <david-sarah at jacaranda.org> 
> wrote:
>> [...] the server needs to be patched in order for a renegotiating 
>> handshake to succeed. If it is patched, then it is TLS- and extension-
>> tolerant.
> 
> That may be(come) true, but most browsers are currently doing fallback to
> SSLv3 when things go wrong during (initial) negotiation. That code is in
> the apps, not the SSL/TLS libraries.
> 
> For that to become true, you'd have to fix all the servers to handle TLS
> (nontrivial in old code I understand) *AND* you'd have to get clients to
> stop falling back to SSLv3. They couldn't stop falling back until the 
> need to fall back (i.e., broken TLS server implementations) disappears, 
> which may take a long time when you consider old code. It will take 
> another long time for browsers to stop falling back.

Not necessarily.  When the browser community perceives that all the old
"TLS-intolerant" (and extension intolerant) servers are all vulnerable, and
when the perception of this vulnerability rises to the point where browser
makers believe their users demand a way to ensure that they no longer
connect to vulnerable servers (and hence become vulnerable), then the
support for fall-back could end rather quickly, I believe.

If the major browser makers all agree, then it might just get cut off cold
at some point.  Otherwise, it might appear as a user configurable option,
and if/when sufficient numbers of users flip that switch, and admins of
vulnerable servers see usage drop off, servers will finally get upgraded.

> So, I agree with Nasko - two mechanisms - an extension for TLS (and TLS 
> *never* sends another Client Hello without the extension), and an SSLv3 
> hack of some sort.

+1

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.