Re: [TLS] interop for TLS clients proposing TLSv1.1

"Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com> Wed, 21 September 2011 22:42 UTC

Return-Path: <yngve@opera.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3FE1F0CE4 for <tls@ietfa.amsl.com>; Wed, 21 Sep 2011 15:42:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.554
X-Spam-Level:
X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VyZXZZMqPpZ for <tls@ietfa.amsl.com>; Wed, 21 Sep 2011 15:42:01 -0700 (PDT)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0490A21F8BF7 for <tls@ietf.org>; Wed, 21 Sep 2011 15:42:00 -0700 (PDT)
Received: from acorna.oslo.osa (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p8LMiKCL015442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Sep 2011 22:44:21 GMT
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
Organization: Opera Software AS
References: <201109212048.p8LKmXnH014242@fs4113.wdf.sap.corp> <op.v16gryhlqrq7tp@acorna.oslo.osa> <6FE09637-CE95-43E8-A3C0-9516E757DDBA@checkpoint.com>
To: "Yoav Nir" <ynir@checkpoint.com>
Date: Thu, 22 Sep 2011 00:44:29 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com>
Message-ID: <op.v16j4famqrq7tp@acorna.oslo.osa>
In-Reply-To: <6FE09637-CE95-43E8-A3C0-9516E757DDBA@checkpoint.com>
User-Agent: Opera Mail/10.63 (Win32)
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] interop for TLS clients proposing TLSv1.1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Sep 2011 22:42:02 -0000

On Wed, 21 Sep 2011 23:47:14 +0200, Yoav Nir <ynir@checkpoint.com> wrote:

> Hi Yngve
>
> On Sep 22, 2011, at 12:32 AM, Yngve N. Pettersen (Developer Opera  
> Software ASA) wrote:
>
>> On Wed, 21 Sep 2011 22:48:33 +0200, Martin Rex <mrex@sap.com> wrote:
>>
>>> Does anyone (SSL Labs, Opera, others) have any figures/stats about the
>>> current "TLSv1.1 version (in)tolerance" for TLS servers on the public
>>> internet?
>>
>> This week's test of 609726 servers gave these numbers:
>>
>>   * 1.145% of the probed servers were version intolerant for at least  
>> one
>> of the current TLS versions (1.0, 1.1, 1.2)
>>   * 1.742% were extension intolerant for the same versions
>>   * 1.136% belonged in both groups
>>
>> This gives an estimated total of 1.751% that are either version and/or
>> extension intolerant for the currently defined TLS versions.
>>
>> These numbers have been decreasing during the past year and a half,  
>> around
>> January 2011 it was 1.951% just for the version intolerant, 2.657% in  
>> may
>> 2010 (the extension numbers are not as detailed for those runs).
>>
>> Most of the version intolerant are intolerant for TLS 1.1 and TLS 1.2,  
>> but
>> some are SSLv3 only servers that are also intolerant for TLS 1.0. There  
>> is
>> even a 0.007% share that support TLS 1.1 (quite a lot of which has "vpn"
>> as the hostname).
>
> By "version intolerant" do you mean that you're sending a TLS 1.1 or 1.2  
> handshake message and the server rejects it?
>
> If you send a TLS 1.0 handshake message, with the version field of the  
> ClientHello showing 1.2, what portion of the servers would reject that  
> (rather than just replying in TLS 1.0)?
>
> Is that something you measure?  If the portion is very low, it could be  
> feasible to implement a client without fallback behavior.


The testing is performed using two record protocol versions: Either 3.0 or
3.1 (starting with 3.0), depending on what actually works

The record version is supposed to be the lowest version the server is  
known to support. At present all clients are AFAIK sending 3.1, unless  
they are offering 3.0 as the highest version, or is trying 3.0 in  
combination with 3.1.

Intolerance is considered present if the server does not negotiate a
version it is known to support, when a higher version than supported is
sent in the Client Hello (e.g 3.1 is known, sending 3.2), and there is
some form of handshake failure (including abrupt connection shutdown)
either as the handshake is sent, or during the handshake, before it is
completed.

There are some servers (0.487%), for example www.mozilla.com, that will
not negotiate TLS 1.0 (0.487%) or TLS 1.1 (0.217%) if the record protocol
is 3.0.

Extension intolerance is detected in a similar fashion.

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
********************************************************************