Re: [TLS] What does "renegotiation_info" mean?

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 13 June 2018 20:09 UTC

Return-Path: <ilariliusvaara@welho.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 5A86B130F7C for <tls@ietfa.amsl.com>; Wed, 13 Jun 2018 13:09:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CT6tfy9bPUqq for <tls@ietfa.amsl.com>; Wed, 13 Jun 2018 13:09:51 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0C48130F6F for <tls@ietf.org>; Wed, 13 Jun 2018 13:09:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id AAAB654A06; Wed, 13 Jun 2018 23:09:48 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id V0isNZISgRfx; Wed, 13 Jun 2018 23:09:48 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 054FD27B; Wed, 13 Jun 2018 23:09:45 +0300 (EEST)
Date: Wed, 13 Jun 2018 23:09:45 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: "Salz, Rich" <rsalz@akamai.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Message-ID: <20180613200945.GA23235@LK-Perkele-VII>
References: <949AFB3D-EAF7-423D-A620-ACCA24AFA26B@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <949AFB3D-EAF7-423D-A620-ACCA24AFA26B@akamai.com>
User-Agent: Mutt/1.10.0 (2018-05-17)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/r6vhjfGYRFc4Ukx4lLg4KMk059E>
Subject: Re: [TLS] What does "renegotiation_info" mean?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.26
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: <https://mailarchive.ietf.org/arch/browse/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, 13 Jun 2018 20:09:54 -0000

On Wed, Jun 13, 2018 at 07:47:11PM +0000, Salz, Rich wrote:
> It seems that the semantics of the "renegotiation_info" extension are
> slightly muddy. Qualys understands it to mean that the server will
> not perform insecure renegotiation, full stop. But OpenSSL further
> understands it to mean that the server *will* perform secure
> negotiation. OpenSSL therefore makes it difficult to simultaneously
> simultaneously satisfy both of Qualys's expectations, since disabling
> all renegotiation will cause it not to send the "renegotiation_info"
> extension. Popular open source web servers implement a workaround
> which achieves Qualys's desired behavior.  Comments?

Then there are the clients that justifiably immediately abort the
handshake if TLS 1.2 server_hello lacks renegotiation_info.

This is because unless client then tries to probe for renegoitiation,
which it can not in practice do because all the servers that just fail
to renegotiate correctly, it can not tell if it is under attack or not.

Not responding to renegotiation_info in TLS 1.2 is a security issue,
even if there is no renegotiation support. OpenSSL should be fixed to
respond to it in TLS 1.0 to 1.2 _regardless_ of if renegotiation is
enabled or not.



-Ilari