[Acme] Issuing certificates based on Simple HTTP challenges

Julian Dropmann <julian@dropmann.org> Mon, 14 December 2015 16:24 UTC

Return-Path: <julian@dropmann.org>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B381A88FD for <acme@ietfa.amsl.com>; Mon, 14 Dec 2015 08:24:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 1rXhzHdgrRws for <acme@ietfa.amsl.com>; Mon, 14 Dec 2015 08:24:51 -0800 (PST)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF7F31A906A for <Acme@ietf.org>; Mon, 14 Dec 2015 08:24:17 -0800 (PST)
Received: by lfcy184 with SMTP id y184so51023530lfc.1 for <Acme@ietf.org>; Mon, 14 Dec 2015 08:24:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dropmann.org; s=dkim1; h=mime-version:date:message-id:subject:from:to:content-type; bh=PVVugyK9Np1ajO/QeQguauNEOKaDMjFIAFRYddf8/xU=; b=RSJDZ4A5CkhcnsF4dRizOEDyoaG1HvDPXqDjS2d7VFFmXHZmFQxejZX5N07z9HXDGJ IAgh0TpMAAfYZNd6C65r6qD09M5dZuNXEkQzgWtynD2XIO7j1FZoZoQBmscz4znrWq4Y p3gDv42wd1IoepA/jm54vlow24hpAm/aQq5P4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=PVVugyK9Np1ajO/QeQguauNEOKaDMjFIAFRYddf8/xU=; b=aGdHsD4vjYBnkHAHLxrmAKWspOzOeVgLqppXLDHdRbR8BKU5J/T8JK2OYM1SIE3XTA 3vE1bZiCeVbQ1wBQtQ0IbDc6NJeAVNCFOQ/6n5BvsM4p3Qe9x9O1w3T2shfXeJrHt8Cw g1c0rvsQXVz+YSsRMMafnsAIQvTW2OYHcG7+RbplqP06Ygzu4s9U1OBFPMlMNoV+6l3k PqD0Gc8NQEi7V+bubOgobF0KDhNM+UmNPQ7WwCQ0OMcpM+NGkcq/HkX94Qc1+g4KhPvk CTu+JR8PfA930iIY0h9Y+HoFX2WfRLNN3s8mloGC932cJbbFhvmi5fd12B+NjMwYDIx8 LwSA==
X-Gm-Message-State: ALoCoQkAgFSuQ5zEDD6t9ITWU99gPJqiFLUZ0UtBpiuu06eb97V1l/bFNxZwhn1eMrea6cvVN+0AZNy+NPhW7EEi132+4SWfSg==
MIME-Version: 1.0
X-Received: by 10.25.137.7 with SMTP id l7mr10912867lfd.63.1450110255817; Mon, 14 Dec 2015 08:24:15 -0800 (PST)
Received: by 10.25.39.2 with HTTP; Mon, 14 Dec 2015 08:24:15 -0800 (PST)
X-Originating-IP: [62.154.225.234]
Date: Mon, 14 Dec 2015 17:24:15 +0100
Message-ID: <CAF+SmEpOLoaREymVhi=qOUg2opz1vKzzNp6tGrDTZAjYSKFDkg@mail.gmail.com>
From: Julian Dropmann <julian@dropmann.org>
To: Acme@ietf.org
Content-Type: multipart/alternative; boundary="001a113fc260af0dac0526de1a4a"
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/KoUxunbzAO_86cSkUfmL_q2ppwc>
Subject: [Acme] Issuing certificates based on Simple HTTP challenges
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Dec 2015 16:27:42 -0000

Hello,

maybe I am just a naive concerned user, but in my opinion there is one
major issue with the Simple HTTP challenge and possibly other challenges,
specified by ACME:

Any host which is specified by an A/AAAA record of that domain zone can
obtain trusted certificates in the name of the domain zone owner.
Lets assume I host an private XMPP server using TLS on my own domain using
an SRV record, and I point an A record to a third party hoster which hosts
my public web blog.
Now this third party hoster would be able to obtain signed certificates for
my domain using ACME and use that to host an XMPP service on that domain
using the standard port.
Clients which trust that CA are now perfectly happy connecting to that
entity.

By creating an A record I ofcourse need to trust that host to some degree,
but I still would expect the CA to verify if the requester has control over
the DNS zone itself an not just over a single service running there.

And consequently if it is valid to verify over HTTP, then maybe another CA
validates the domain ownership by a mail service/MX record, and a third one
over XMPP/SRV.

This effectively means, as a domain zone admin, I have to trust every
single service I define, not just to properly deliver this service, but
also not to exploit his ability to obtain signed certificates in my name.

Also you rely on the fact that on UNIX only root can bind on port 80 and
443. Lets assume there is an OS out there which does not enforce this
restriciton,
now any user on that host is able to obtain signed certificates for that
domain.

Maybe I missed something here, but overall this seems to be a very bad idea
to automatically issue certificates without requiring a change in the
actual DNS zone the certificate is issued for.

Kind regards,
Julian Dropmann