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

"Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com> Wed, 21 September 2011 23:17 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 997F511E8095 for <tls@ietfa.amsl.com>; Wed, 21 Sep 2011 16:17:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.558
X-Spam-Level:
X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 XEJH9YjSjFVD for <tls@ietfa.amsl.com>; Wed, 21 Sep 2011 16:17:03 -0700 (PDT)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 853E611E8073 for <tls@ietf.org>; Wed, 21 Sep 2011 16:17:03 -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 p8LNJUt6021066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Sep 2011 23:19:31 GMT
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: "Martin Rex" <mrex@sap.com>
References: <201109212230.p8LMUmc2020172@fs4113.wdf.sap.corp>
Date: Thu, 22 Sep 2011 01:19:38 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com>
Organization: Opera Software AS
Message-ID: <op.v16lq0saqrq7tp@acorna.oslo.osa>
In-Reply-To: <201109212230.p8LMUmc2020172@fs4113.wdf.sap.corp>
User-Agent: Opera Mail/10.63 (Win32)
Cc: 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 23:17:04 -0000

On Thu, 22 Sep 2011 00:30:48 +0200, Martin Rex <mrex@sap.com>; wrote:

> Yngve N. Pettersen 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.
>
> OK, I'll try to be more specific about the numbers that
> *I* would be interest in (in case you could extract from your data):
>
> When sending an SSLv3 ClientHello (i.e. {0x03,0x00} at the record layer),
> how many servers abort immediately, depending on the value of the
> client_version:
>
>     for client_version = { 0x03,0x00 }   (SSLv3)
>     for client_version = { 0x03,0x01 }   (TLSv1.0)
>     for client_version = { 0x03,0x02 }   (TLSv1.1)
>     for client_version = { 0x03,0x03 }   (TLSv1.2)
>
> and how many continue the handshake but fail the finished macs?

I am currently not registering data that detailed (although I do register  
results for each tested client_version value tested, the results are not  
that fine-grained), and IMO it does not really make that much a difference  
(to the client) if the server just shut down the connection, or failed the  
finished message; establishing the connection still failed.

As mentioned earlier I do register servers that refuse to accept a SSL v3  
record protocol for the Hello, but require a TLS 1.0 instead (the number  
of servers that require that, and are included in the above version  
intolerance count is 29, 0.005 percentage points)

One case where we do (implictly) get a failure during the finished mac, is  
for the 0.117% of servers that mirror any version back, even if they do  
not support it.

The number of servers that require the RSA client key exchange version  
field to be the same as the negotiated version, not sent version, is about  
4.6% (April 2011; data not reliable since then :( ): about 27% ignore that  
version field.

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