Subject: [TLS] Opera 10.50 alpha snapshot with TLS Renego extension support

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Sat, 23 Jan 2010 16:08:42 +0100

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)
     * 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.
     * 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.

Opera's implementation also contain an auto-updatable preference that can
(step 1) be used to get Opera installations to display certificate warning
dialogs for unpatched server, and (step 2) to disable support for unpatched
servers. If and when these updates will be used is currently undecided.

Additionally, a heads up: I've recently been doing some probing of TLS
servers and among a 100 000+ sample 40+% of the servers did not check the
RSA Premaster secret at all, and 0.7% required the wrong version (the
negotiated version) in this field. Another finding is that 60+% of the
tested servers did not tolerate the ClientHello.version field being set
to 4.1, which could cause problems if/when the major version number of
TLS is updated.

Further information and download links can be found at:

    <http://my.opera.com/desktopteam/blog/continued-stabilization >
    <http://my.opera.com/securitygroup/blog/2010/01/23/alpha-testing-tls-renego-fix  

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: Wan-Teh Chang <[email-masked]>
Date: Sat, 23 Jan 2010 09:09:24 -0800

On Sat, Jan 23, 2010 at 7:08 AM, Yngve N. Pettersen (Developer Opera
> 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
that contradicts your first bullet point, that you send the RI
extension in *all* handshakes.

>    * 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

I don't understand what you meant by "will abort ongoing handshakes
if it not already identifying with TLS 1.2".

> first indicate support for RI, then later (in the same session) fail to

In the same browsing session or in the same SSL session?

Thanks for the statistics on various TLS server implementation
errors.

Wan-Teh

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Sat, 23 Jan 2010 18:46:53 +0100

> 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.

> extension in *all* handshakes.

"in all handshakes [that uses] Extensions"

> 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.

> 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