Re: [websec] Certificate Pinning via HSTS (.txt version)

Yoav Nir <ynir@checkpoint.com> Tue, 13 September 2011 18:39 UTC

Return-Path: <ynir@checkpoint.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D29A411E8099 for <websec@ietfa.amsl.com>; Tue, 13 Sep 2011 11:39:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.382
X-Spam-Level:
X-Spam-Status: No, score=-10.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 Yw5RK-i5Vw6X for <websec@ietfa.amsl.com>; Tue, 13 Sep 2011 11:39:05 -0700 (PDT)
Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id DA3CF11E8095 for <websec@ietf.org>; Tue, 13 Sep 2011 11:39:04 -0700 (PDT)
X-CheckPoint: {4E6FB0EE-5-1B221DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p8DIf9LT028774; Tue, 13 Sep 2011 21:41:09 +0300
Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 13 Sep 2011 21:41:09 +0300
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Tue, 13 Sep 2011 21:41:09 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Peter Saint-Andre <stpeter@stpeter.im>
Date: Tue, 13 Sep 2011 21:41:08 +0300
Thread-Topic: [websec] Certificate Pinning via HSTS (.txt version)
Thread-Index: AcxyRLPdnQp/cCwpRjyXirRP0HCT7Q==
Message-ID: <FA8A58ED-DD2B-446B-9F01-9D1D25140569@checkpoint.com>
References: <4E6E9B77.1020802@KingsMountain.com> <4E6F9DC6.2080006@stpeter.im>
In-Reply-To: <4E6F9DC6.2080006@stpeter.im>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-KSE-AntiSpam-Interceptor-Info: protection disabled
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] Certificate Pinning via HSTS (.txt version)
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Sep 2011 18:39:05 -0000

On Sep 13, 2011, at 9:15 PM, Peter Saint-Andre wrote:

> On 9/12/11 5:53 PM, =JeffH wrote:
>> 
>> This is great, thanks for posting this here.
>> 
>> I have various comments on it I'll try to get to in the next day or so.
>> 
>> During HSTS's gestation, various parties have discussed potential
>> "LockCA" and "LockEV" directives ostensibly having similar semantics to
>> what you've proposed here (see talk slides from last few websec sessions
>> at IETF meetings). (though I think recent events pretty much obviate
>> those nominal ideas because they'd relied on the resilience of one's CA
>> and the CA infrastructure (oops))
> 
> <hat type='individual'/>
> 
> Jeff, why do you say that? It seems to me that if you think various CAs
> are dodgy or vulnerable, but you know and like the policies of the CA
> you're using, you might well want to lock into that CA.

As a customer, I have very little insight into the policies of the CA I'm using. For all I know, the actual signing may be done on a server, accessible from the Internet through SSH with the user "root" and the password "password", and then it's just an OpenSSL script conveniently located along with the private key in root's home directory.

Alternatively, it's possible that the private key is stored on the web server and accessible as http://www.exampleca.com/../ca.key

Locking yourself into a CA like that seems like a bad idea. Unlike the Dutch government and Mozilla, most customers do not have the pull to force CAs to submit to audits.

Six months ago we would not have thought that Comodo or DigiNotar were easy to hack. In the latter case, the customers of DigiNotar were left out in the cold. Without certificate pinning, they just need to spend money on a new certificate and their site is working again. With it, they are in trouble.