[TLS] Certificate handshake message - common config problems

Martin Rex <mrex@sap.com> Fri, 29 January 2010 17:15 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 084FB3A6837 for <tls@core3.amsl.com>; Fri, 29 Jan 2010 09:15:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.949
X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id eOh2TkYkdUWa for <tls@core3.amsl.com>; Fri, 29 Jan 2010 09:15:31 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de []) by core3.amsl.com (Postfix) with ESMTP id AA6AA3A672F for <tls@ietf.org>; Fri, 29 Jan 2010 09:15:30 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id o0THFpVv005770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <tls@ietf.org>; Fri, 29 Jan 2010 18:15:51 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201001291715.o0THFov6024039@fs4113.wdf.sap.corp>
To: tls@ietf.org
Date: Fri, 29 Jan 2010 18:15:50 +0100 (MET)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Subject: [TLS] Certificate handshake message - common config problems
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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/listinfo/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: Fri, 29 Jan 2010 17:15:32 -0000

Dear TLS,

I have just analyzed an interop problem reported by a customer
that was caused by a misconfigured apache web server of a third

The problem is, that this apache sends a Certificate message
that contains the EndEntity certificate twice in a row,
followed by an otherwise correct chain of 3 CA certificates.

Browsers like Firefox and MSIE do not report this as an error.
MSIE doesn't barf, because AFAIK it applies a generic cert chain building
algorithm to all certs following the initial end entity cert.  I don't
know what kind of algorithm firefox uses in order to eliminate the
duplicated end entity cert.

The cause of the problem is the lack of consistency checks performed
by OpenSSL when building the certificate_list in Certficate handshake
messages.  The SSL&TLS spec are clear that what this server is sending
is not compliant to the protocol.  The only one able to fix this
configuration problem is the operator of the server, and the one
who would be able to prevent this problem from occurring is OpenSSL.

I think it that original protocol requirement (well-formed cert chain)
is a very useful protocol feature, because it can save code,
dynamic memory footprint and cpu-cycles, and it also leads to
much more consistent results if everyone validates _the_same_
certificate path.  Having OpenSSL build the chain before
sending it (in addition to when receiving it) might be a good
idea -- and could catch other errors, such as missing intermediate
certs, immediately and under control of those who are able to
and responsible for fixing it.

What do other implementers think about this issue?