Re: [TLS] To extend or not to extend

[Bodo Moeller <[e-mail]>]

On Nov 15, 2009, at 1:14 PM, Nelson B Bolyard wrote:

> On 2009-11-15 03:38 PDT, Eric Rescorla wrote:
>
>> So, thinking further on my earlier message, I think the following
>> elaboration will work a bit better:
>>
>> - Strict clients (those which wish to insist on RI) generate RI on
>>  initial handshake. As I said earlier, I don't think this is
>>  useful, but it works.
>>
>> - Lenient clients do not generate RI on initial handshake but do
>>  generate it on rehandshake with TLS 1.0+ only.
>>  + Moderately lenient clients can fail if the server does not
>>    do RI.
>>  + Really lenient clients can ignore the server's failure to
>>    do RI.
>
> Aren't your so-called Lenient clients still 100% vulnerable to the  
> attack?
>
> What prevents their initial handshakes from being used by an  
> attacker as
> renegotiations with a vulnerable server?

Not connecting to a vulnerable server would.  In the web browser  
scenario, if I know that the HTTPS servers I use for serious purposes  
are not vulnerable (i.e. don't allow renegotiation, other than  
possibly with the updated renegotiation protocol), I'm fine.

When an HTTP page points me to an HTTPS page that I haven't heard of  
before, where I wouldn't even bother to verify the certificate's  
subject name or the hostname, then I don't care at all: I don't know  
if the entity that owns the certificate is who I think is running the  
site anyway.  Maybe a "Man-in-the-Middle" style attacker is handling  
all my connections and forwarding them to the real server in TLS  
renegotiation handshakes -- so what?  The attacker could just as well  
have directed me to another domain for which they have a certificate.   
If there's no active attacker, I'm fine to the extent that it's  
possible: my traffic is at least safe from passive eavesdroppers.   
Without a lenient client, I'll actually lose something if the servers  
haven't been upgraded because I might have to fall back to an  
unencrypted connection instead.

Bodo