Re: [TLS] Proposal for detecting fraudulent certificates
Florian Weimer <fweimer@bfk.de> Mon, 26 September 2011 16:18 UTC
Return-Path: <fweimer@bfk.de>
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 0BBBF21F8CE9 for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 09:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.352, BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 z1v6fkCm6YBp for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 09:18:47 -0700 (PDT)
Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3E921F8CD9 for <tls@ietf.org>; Mon, 26 Sep 2011 09:18:47 -0700 (PDT)
Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1R8Dvt-0006vQ-IX; Mon, 26 Sep 2011 16:21:29 +0000
Received: by bfk.de with local id 1R8Dvt-0001ts-Fq; Mon, 26 Sep 2011 16:21:29 +0000
From: Florian Weimer <fweimer@bfk.de>
To: mrex@sap.com
References: <201109261605.p8QG5vRC013367@fs4113.wdf.sap.corp>
Date: Mon, 26 Sep 2011 16:21:29 +0000
In-Reply-To: <201109261605.p8QG5vRC013367@fs4113.wdf.sap.corp> (Martin Rex's message of "Mon, 26 Sep 2011 18:05:57 +0200 (MEST)")
Message-ID: <82y5xb9svq.fsf@mid.bfk.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: tls@ietf.org
Subject: Re: [TLS] Proposal for detecting fraudulent certificates
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: Mon, 26 Sep 2011 16:18:48 -0000
* Martin Rex: > Having the client send _only_ the servers certificate and not the > entire certificate path should IMO be sufficient for the purpose you > outline. I don't think it is. The certificate itself is not proof of fraud if an intermediate CA is involved. More importantly, you cannot tell an intercepting corporate proxy (whose certificate is not rooted in the browser PKI) from a certificate which is. > I don't know why you think the 64 KByte TLS extension size limit would > be a problem. The wire format allows for larger server chains (up to 16 MB). This could be abused to bypass detection (just use a certificate with a logotype extension). I just felt I had to say something about that. > But I don't see how this extension could realistically work in a > sane fashion. The TLS implementation in TLS servers is not normally > keeping a history of previous TLS Server certificates which it ever > used (and might not have a persistence of its own for such a purpose), > usually not even across process restarts, and having TLS backends of > a Web-Server-Farm or hot-backups keep such a history in a consistent > fashion is even more unlikely. The TLS server doesn't have to keep this information. It just has to log it or export it over an out-of-band mechanism to the application (similar to what's already done for client certificates). Client hellos are clear text, so you would see the extension on an IDS host, too. > And end users would probably prefer their TLS clients to tell them right > away when a server credential changes unexpectedly, rather than > a TLS server telling them, after they come home from a several weeks > trip through some contry YYY, that their last several week of connect(s) > had all been MITMd... This has UI issues which appear to unsolvable. And even in web browsers, not all TLS activity is user-initiated (e.g., software and filter list updates). Thanks for your comments. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
- [TLS] Proposal for detecting fraudulent certifica… Florian Weimer
- Re: [TLS] Proposal for detecting fraudulent certi… Martin Rex
- Re: [TLS] Proposal for detecting fraudulent certi… Florian Weimer
- Re: [TLS] Proposal for detecting fraudulent certi… Max Pritikin
- Re: [TLS] Proposal for detecting fraudulent certi… Martin Rex
- Re: [TLS] Proposal for detecting fraudulent certi… Florian Weimer