Re: exposing certificate information (current + upcoming)

Stefan Eissing <stefan.eissing@greenbytes.de> Sat, 11 May 2019 12:41 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821A512008B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 11 May 2019 05:41:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.998
X-Spam-Level:
X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=greenbytes.de header.b=mpNCcfO1; dkim=pass (1024-bit key) header.d=greenbytes.de header.b=mpNCcfO1
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 V9eRUjUyza7Y for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 11 May 2019 05:41:12 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3B6120026 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 11 May 2019 05:41:12 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hPRGL-00057G-Rp for ietf-http-wg-dist@listhub.w3.org; Sat, 11 May 2019 12:38:01 +0000
Resent-Date: Sat, 11 May 2019 12:38:01 +0000
Resent-Message-Id: <E1hPRGL-00057G-Rp@frink.w3.org>
Received: from mimas.w3.org ([2603:400a:ffff:804:801e:34:0:4f]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <stefan.eissing@greenbytes.de>) id 1hPRGI-00056P-NT for ietf-http-wg@listhub.w3.org; Sat, 11 May 2019 12:37:58 +0000
Received: from mail.greenbytes.de ([217.91.35.233]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <stefan.eissing@greenbytes.de>) id 1hPRGG-0003Gq-BN for ietf-http-wg@w3.org; Sat, 11 May 2019 12:37:58 +0000
Received: by mail.greenbytes.de (Postfix, from userid 117) id CBEC815A1294; Sat, 11 May 2019 14:37:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=greenbytes.de; s=mail; t=1557578253; bh=Q7Q4UhpOpuz9gme9rDR4rYUxUX66RIwCnacuIK/01ok=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=mpNCcfO1h9zPaiCWRAA0yuHawaaPis7tZIlkF6PmvlGXKzklH03xxu0fLREpxDqGz eJWslcNC/imLMxePsB4VGXD6z7/V36UAWsiVnPH/crwCDI0YORAjtpGVwws/snRNQc dOREP6bo5a6xh2oUOm7paHCDAyLU6FHD4veyftks=
Received: from [192.168.178.61] (unknown [93.207.152.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 0C95F15A0448; Sat, 11 May 2019 14:37:32 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=greenbytes.de; s=mail; t=1557578253; bh=Q7Q4UhpOpuz9gme9rDR4rYUxUX66RIwCnacuIK/01ok=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=mpNCcfO1h9zPaiCWRAA0yuHawaaPis7tZIlkF6PmvlGXKzklH03xxu0fLREpxDqGz eJWslcNC/imLMxePsB4VGXD6z7/V36UAWsiVnPH/crwCDI0YORAjtpGVwws/snRNQc dOREP6bo5a6xh2oUOm7paHCDAyLU6FHD4veyftks=
Content-Type: multipart/alternative; boundary="Apple-Mail-B4B9698D-DC90-42C2-9EAE-C17CD826C93B"
Mime-Version: 1.0 (1.0)
From: Stefan Eissing <stefan.eissing@greenbytes.de>
X-Mailer: iPhone Mail (16E227)
In-Reply-To: <CAErg=HG9LecgAPusJQtgLMf44kz_yMmvCp+Ai_NAEN_Q3JxWfQ@mail.gmail.com>
Date: Sat, 11 May 2019 14:37:32 +0200
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: 7bit
Message-Id: <3B15B459-75E6-457B-8198-590B4C0B97A2@greenbytes.de>
References: <BA35C55E-E096-49DA-BBC5-D5A34756FC67@greenbytes.de> <CAErg=HG9LecgAPusJQtgLMf44kz_yMmvCp+Ai_NAEN_Q3JxWfQ@mail.gmail.com>
To: Ryan Sleevi <ryan-ietf@sleevi.com>
Received-SPF: pass client-ip=217.91.35.233; envelope-from=stefan.eissing@greenbytes.de; helo=mail.greenbytes.de
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1hPRGG-0003Gq-BN 87ce95025d3226894ac87ad4fbd51f1e
X-Original-To: ietf-http-wg@w3.org
Subject: Re: exposing certificate information (current + upcoming)
Archived-At: <https://www.w3.org/mid/3B15B459-75E6-457B-8198-590B4C0B97A2@greenbytes.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36632
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

As I understood Christophs use case, he wants to monitor CT logs for newly issued certificates for any domain of his. To verify that the new certificate was indeed obtained by one of his servers/devices he would like to ask them.

If the server does not list the cert as incoming, someone else might have spoofed the CA into issueing it.

This helps if a new cert is not immediately activated on the device running ACME. A delay of such activation is practically 0 on many servers, but can extend to days on others. With Apache, it is controlled by the admin. A server with several hundred or thousands hosted domains will aggregate restarts most likely, for example.

The idea of an automated domain monitor that can warns you within a short time that a renewal was not done by the box handling the domain, seems legit.

- Stefan

> Am 10.05.2019 um 19:48 schrieb Ryan Sleevi <ryan-ietf@sleevi.com>:
> 
> 
> 
>> On Fri, May 10, 2019 at 6:50 AM Stefan Eissing <stefan.eissing@greenbytes.de> wrote:
>> Christophe Brocas (@cbrocas), organizer of Pass-the-Salt security conference, tweeted 
>> about checking HTTP server certificates against CT logs to detect very early if someone
>> successfully highjacked one of your domains.
>> 
>> A renewed certificate is often not immediately used on a server but activated on the
>> next restart which can be several hours away. To check if a certificate mentioned in a
>> CT log, one would need to obtain information about upcoming certificates as well.
> 
> I'm not sure I understand the CT use case. Are you attempting to verify that a certificate with embedded SCTs has been incorporated within a logs MMD? The discussion of detecting very early if someone hijacked one of your domains seems largely orthogonal to providing information about your present certificate, since the attacker/adversary would simply not provide this information. In CT, this is fine, because the reliance is upon the SCTs (whether from TLS, embedded, or OCSP) being proof of inclusion within a log, and, as Ilari mentioned, client verification and/or gossip of those SCTs (and related STHs) to ensure presence within a log.
> 
> While I don't think there's any harm in exposing information about upcoming certificates, particularly if they've already been logged (by the server, in the case of TLS, or by the CA, in the case of embedded SCTs or OCSP responses), it doesn't seem to fit with a very clear threat model, and I worry I'm missing something that's supposed to be obvious here.