[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] Opera 10.50 alpha snapshot with TLS Renego extension support
From:       "Yngve N. Pettersen (Developer Opera Software ASA)" <yngve () opera ! com>
Date:       2010-01-23 17:46:53
Message-ID: op.u6zycfprqrq7tp () acorna ! oslo ! opera ! com
[Download RAW message or body]

On Sat, 23 Jan 2010 18:09:24 +0100, Wan-Teh Chang <wtc@google.com> wrote:

> On Sat, Jan 23, 2010 at 7:08 AM, Yngve N. Pettersen (Developer Opera
> Software ASA) <yngve@opera.com> wrote:
>> Hello all,
>>
>> Today Opera Software released a snapshot of Opera 10.50 alpha with  
>> support
>> for the TLS RenegotiationInfo extension.
>>
>> Server vendors should note the following:
>>
>>    * The RI extension is sent in all handshakes using extensions
>>    * The SCSV is only sent when we do not know if the server supports
>> extensions (implied: Patched servers always support the RI extension)
>
> Could you clarify one issue -- when you send SCSV, do you also
> send an empty RI extension?  Your second bullet point implies
> that when you send SCSV, you don't send any extension.  But

Whenever we send extensions the RI extension is sent.

Independently of this, if we do not know if the server supports or  
tolerates extensions we send the SCSV, but it can be sent in combination  
with the extensions. We send the SCSV during the initial feature probe  
(which may include sending extensions) and in the SSL v3/TLS v1.0 without  
extension modes.

> that contradicts your first bullet point, that you send the RI
> extension in *all* handshakes.

"in all handshakes [that uses] Extensions"

>>    * Against known patched servers Opera 10.50 will ONLY send Client  
>> Hellos
>> identifying TLS 1.2 as the highest supported version, and will abort  
>> ongoing
>> handshakes if it not already identifying with TLS 1.2. It will **NOT**  
>> fall
>> back to an older version if negotiation fails. Patched servers are  
>> assumed
>> to be version tolerant.
>
> I don't understand what you meant by "will abort ongoing handshakes
> if it not already identifying with TLS 1.2".

If we discover that the server supports RI during an initial handshake  
that did not identify TLS 1.2 as our highest supported version, we shut  
down the connection, and restart negotiation with a Hello identifying TLS  
1.2 as our highest version. Normally this means that upon first connection  
we will send a TLS 1.0 hello without extensions, get the RI extension  
back, shut down (which we would have anyway in most cases), and set up a  
new connection with the TLS 1.2 handshake. This can also occur for  
connection where we have previously determined version/extension  
configuration (which is usually cached for 4 weeks), but have never tested  
RI support. This procedure protects against potential version downgrade  
attacks.

>>    * It is a fatal error for a server (identified by hostname and port)  
>> to
>> first indicate support for RI, then later (in the same session) fail to
>> indicate support.
>
> In the same browsing session or in the same SSL session?

Same browsing session. Sorry for not being clear. We don't store a renego  
flag, but do cache the use of TLS 1.2 with extension. Since the eventual  
plan is to move to required RI support browse session only should be  
sufficient.

The scenario where this is likely to occur is multi-machine servers where  
not every machine has been updated.



-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

[prev in list] [next in list] [prev in thread] [next in thread]