Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC
Geoffrey Keating <geoffk@geoffk.org> Mon, 04 October 2010 16:17 UTC
Return-Path: <geoffk@geoffk.org>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 906273A6FD9 for <tls@core3.amsl.com>; Mon, 4 Oct 2010 09:17:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaD3dbPlBQUk for <tls@core3.amsl.com>; Mon, 4 Oct 2010 09:17:30 -0700 (PDT)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by core3.amsl.com (Postfix) with ESMTP id 76DC93A6FC5 for <tls@ietf.org>; Mon, 4 Oct 2010 09:17:30 -0700 (PDT)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id CDED833D0FD; Mon, 4 Oct 2010 16:18:24 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Ralph Holz <ralph-tls-tum@ralphholz.de>
References: <201010041437.o94EbTHT029454@fs4113.wdf.sap.corp> <4CA9F8BC.3090704@ralphholz.de>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: Mon, 04 Oct 2010 09:18:24 -0700
In-Reply-To: <4CA9F8BC.3090704@ralphholz.de>
Message-ID: <m2r5g6j5in.fsf@localhost.localdomain>
Lines: 35
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: tls@ietf.org
Subject: Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/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: Mon, 04 Oct 2010 16:17:31 -0000
Ralph Holz <ralph-tls-tum@ralphholz.de> writes: > Hi, > > > But keep in mind that few TLS clients (such as browsers), currently > > support "pinning" of PKIX-authenticated server certs, so that on future > > connects only the very same server cert (with user-authenticated > > attributes other than DNS f.q.d.n) will be accepted from that server. > > In is very common misbehaviour in TLS clients to accept arbitrary other > > server certs on future connects, as long as the DNS f.q.d.n matches. > > I have found during a few tests that some companies which give different > IPs for the same DNS name also run some servers with different certs > than the "main one". A closer look at the certs revealed that they had > been issued for the same domain and had been signed by the same CA, i. > e. they were perfectly valid. Pinning certs would prohibit this kind of > behaviour. > > Although I am not sure it is intentional - my thought was that these > servers were just misconfigured (older cert?), as only very few > exhibited this behaviour. Some CAs license their certificates for use on a single server. If these companies were using one of these CAs, they may have bought multiple certificates for the same DNS name. This might be done even if the CA doesn't require it, as a security/reliability measure, so that machines do not need to share private keys. This can also happen for the same IP address, if it's a load balancer with several servers behind it. It can also happen if the systems serve different combinations of DNS names: one machine serves www.a.com and another serves both mail.a.com and www.a.com so they have different certificates.
- [TLS] Cert Enumeration and Key Assurance With DNS… Phillip Hallam-Baker
- Re: [TLS] Cert Enumeration and Key Assurance With… Ben Laurie
- Re: [TLS] Cert Enumeration and Key Assurance With… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Matt McCutchen
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Ben Laurie
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Marsh Ray
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Peter Gutmann
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Phillip Hallam-Baker
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Tony Finch
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Michael StJohns
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Tony Finch
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Marsh Ray
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Ralph Holz
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Stephen Farrell
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Geoffrey Keating
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] Cert Enumeration and Key Assurance With… Ondřej Surý
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Jeffrey A. Williams
- Re: [TLS] Cert Enumeration and Key Assurance With… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Phillip Hallam-Baker
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Jakob Schlyter
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Michael StJohns
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Andrew Sullivan
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Jeffrey A. Williams
- [TLS] OtherCerts & pinning (Was: Re: [pkix] Cert … Stephen Farrell
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Kemp, David P.
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Ralph Holz
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Ondřej Surý
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Jeffrey A. Williams
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Seth David Schoen
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Marsh Ray
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Stephen Kent
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Paul Hoffman
- Re: [TLS] Cert Enumeration and Key Assurance With… Nicolas Williams
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Marsh Ray
- Re: [TLS] [saag] [pkix] Cert Enumeration and Key … Peter Gutmann
- Re: [TLS] [saag] [pkix] Cert Enumeration and Key … Yaron Sheffer
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Henry B. Hotz
- Re: [TLS] [saag] [pkix] Cert Enumeration and Key … der Mouse
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Carl Wallace
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Jeffrey A. Williams
- Re: [TLS] [DNSOP] [saag] [pkix] Cert Enumeration … Doug Barton
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Bruno Harbulot
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Phillip Hallam-Baker
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Martin Rex
- Re: [TLS] [pkix] Cert Enumeration and Key Assuran… Jeffrey A. Williams
- Re: [TLS] [DNSOP] [pkix] Cert Enumeration and Key… Paul Wouters