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

Geoffrey Keating <> Wed, 21 September 2011 22:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B33751F0D0F for <>; Wed, 21 Sep 2011 15:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZsqfxUfLzdEq for <>; Wed, 21 Sep 2011 15:52:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 426B81F0CF9 for <>; Wed, 21 Sep 2011 15:52:08 -0700 (PDT)
Received: by (Postfix, from userid 501) id 8128933D145; Wed, 21 Sep 2011 22:54:35 +0000 (UTC)
Sender: geoffk@localhost.localdomain
References: <>
From: Geoffrey Keating <>
Date: 21 Sep 2011 15:54:35 -0700
In-Reply-To: <>
Message-ID: <m27h51ecb8.fsf@localhost.localdomain>
Lines: 43
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [TLS] interop for TLS clients proposing TLSv1.1
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Sep 2011 22:52:08 -0000

Martin Rex <> writes:

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

I find that about 1.4% of servers will refuse to connect using a TLS 1.2
hello but will connect using a TLS 1.0 hello.  Some of those might be
unhappy about something else in the TLS 1.2 hello (extensions, for
example).  The other 99% accept a TLS 1.2 hello, even though only a small
fraction (about 0.15%) actually supports TLS 1.1 or 1.2.

> The TCP RST in the above situation, as described in Stevens' Network
> Programming, Section 7.5, Socket Option SO_LINGER, only indicates the
> specific SO_LINGER setting that the server had used for his side
> of the connection / his socket (Fig. 7.10  close() l_onoff=1, l_linger=0)
> The SO_LINGER setting for a socket is entirely at the discretion of each peer
> and closing the socket immediately after sending a fatal alert is exactly
> what the TLS spec suggests:
>    7.2.2. Error alerts
>    Error handling in the TLS Handshake protocol is very simple. When an
>    error is detected, the detecting party sends a message to the other
>    party. Upon transmission or receipt of an fatal alert message, both
>    parties immediately close the connection. 
>           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^!

RFC 793 says, in section 3.5, that a connection is closed by sending a
FIN.  A RST is not a close of the connection but an abort; as RFC 793
says, "Such a message indicates to the site B TCP that something is
wrong, and it is expected to abort the connection."

However, the question of how to close the connection is secondary,
because it should not have been closed in the first place; as the blog
entry says, "The server isn't supposed to behave this way---it's
instead expected to simply reply using the latest HTTPS protocol
version it supports".  You can't really expect software that's broken
in one way to work perfectly in all other ways...