[Acme] Validation Vulnerabilities

moparisthebest <admin@moparisthebest.com> Fri, 05 June 2015 12:59 UTC

Return-Path: <admin@moparisthebest.com>
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 17B721B2F29 for <acme@ietfa.amsl.com>; Fri, 5 Jun 2015 05:59:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.699
X-Spam-Level:
X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
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 jIdLEHeT2Dm5 for <acme@ietfa.amsl.com>; Fri, 5 Jun 2015 05:59:22 -0700 (PDT)
Received: from mailer.moparscape.org (mailer.moparscape.org [144.76.72.168]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FABC1B2F28 for <acme@ietf.org>; Fri, 5 Jun 2015 05:59:20 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at burtrum.org
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=moparisthebest.com; s=2013; t=1433509155; bh=8frrQN5nYF8qTOFIHyVAq8aFI4+pKi8kYUGndpKR5Gc=; h=Date:From:To:Subject:From; b=AXuHqOm0T6EPjANKD2GZtBYEzYUfmKH00vUMQFEvjkKzGm+w6GljO/2HhCBwN4EOA R+15d1MpTSFcIpgcsJJiRCps7ICA7GUkBxUNNDvHcCEKVZoyMIzjASMniVt1ZfQ5OV Cdy8AbCLoAMgjvLyXnu9mGrY/6WTDBSNuogmkNXg=
Message-ID: <55719D59.6050800@moparisthebest.com>
Date: Fri, 05 Jun 2015 09:00:09 -0400
From: moparisthebest <admin@moparisthebest.com>
MIME-Version: 1.0
To: acme@ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/s6Q5PdJP48LEUwgzrVuw_XPKCsM>
Subject: [Acme] Validation Vulnerabilities
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: <http://www.ietf.org/mail-archive/web/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: Fri, 05 Jun 2015 13:00:59 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello all,

These vulnerabilities would allow an attacker who doesn't control a
domain to get a certificate for that domain, and are basically due to
problems with DNS.

Basically I noticed a comment here:
https://github.com/letsencrypt/boulder/issues/11#issuecomment-103897922
which says letsencrypt won't support DNS validation at the start
because of vulnerabilities, but the problem is all other forms of auth
(DVSNI/Simple HTTPS) also rely on the same DNS to look up the domain
name to connect to, and are therefore subject to the same vulnerabilitie
s.

The *correct* and only perfect solution to this is only allowing
DNSSEC signed responses for any of the above validation tests.  This
means that if a response is properly covered by DNSSEC, none of the
following hacks need to be applied.  But since we don't live in a
perfect world, I'll propose some things that attempt to work around
the issues without DNSSEC:

1. Only allowing DNS over TCP instead of UDP would prevent a
non-man-in-the-middle attacker from sending a well-timed UDP response
with a fake DNS record in it.
2. A man-in-the-middle could hijack DNS queries and send back whatever
responses they want, this could be at the datacenter, bandwidth
provider, or even a nation-state style attacker.  Here are some crazy
ideas to attempt to prevent this:

    a. Have the validator perform DNS queries from 2 different
providers in 2 different geographic locations with 2 different
backbones (via a secure channel between servers, ssh/vpn etc), and
fail if the response is not the same.  For example a server in china
and the usa would likely not have the same man-in-the-middle able to
forge both responses.
    b. Have the validator perform the DNS queries from the server
directly then over TOR, or maybe over TOR multiple times requesting a
different exit node each time, and if the same response isn't returned
each time then fail.
    c. Query different DNS providers over a secure protocol like
DNSCurve or something, and fail if responses are different, OpenDNS is
the only one I know of that supports this right now.

The catch with methods a-c though are they fail with a load-balanced,
geographic-specific, or round-robin DNS, but then maybe fancy large
setups like that don't need automatic certificates?  Or maybe instead
of failing if the IPs were different, you just perform whatever test
you were doing on each of the IPs and verify that it passes against
all IPs.

I don't know if these implementation details should be mentioned in
the ACME spec per-say, or if they should just be
implementation-specific like in boulder, but I feel the
vulnerabilities should be mentioned at the least if not work-around idea
s.

I cross-posted this from
https://github.com/letsencrypt/acme-spec/issues/131

Thanks,
moparisthebest
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQQcBAEBCgAGBQJVcZ1ZAAoJEOy5uMuqxowDmlcgAJ01jiuTiMPKXdF5nFPOc4y/
yaBAVwKsBwx18kDfCO8wjDRoPKh5Y/srzMlwv6FDqlxs6ZbjKLHNbV6dFEn9+dNu
8Dd5c1073B2tv1Ln1Ml/H249Ma1s+mlu5nN2xdAY18as793jpyXvhBa7pERw3H7H
kOhyEMi8FBl3OXDQnXv1b9gkl2LUG2rJGiTAKRw9YDf3sssxNM7BI+ghYCqtpedW
hqFQrX3opNwVsQrXlDDxe4j3YhRe2R25OtGFgJtzhifP1Isr3k2GgkshQi7QI+o2
T3KMBpTCFuaVsY8i4N8fu1FQRVsnUoWtfRcZjAtZa4qmWLWndnvIFTVwBrnhqp7m
3qOynRYB2rQ06RPGM8y04ORW8g0KjYx22QX8mbPjku7PrBQE6y3oTWN3TbILqy3L
5KNVAoBIaDiZ4eAYi7Uol9CPqI8rvlyR5smazSizsFZDHx9FzEthtL9Q2doWyTWM
YGQKRpNjC85QY83etx4tuGkGNduxr6HeZxyhLGIePTiJixq8VNyKIy+YfqKuaBDK
tWJcm7kJoFexbqJJqrHTGe0dv23UwUJs9TyJAK5JMOUjG2CC5emc9menmcftyrzo
2yMTaSjXEYTZU9vqaDN/0+vzkszPPd71X1feJOB/blWV9WMeVq8gXK0kQfIAnZdq
kT4me9KGU80nbMbMLfqYg2HXuUxT2zpwA6smjsaOt0cde/drIReJVpBmWhz/qiPg
uKfCoS7wO5Eb+H9SOpPBoKFoskNufd3vvDCT0MNomEJTUsYMNf7GnrOuDsCzyc9V
FT6tHX3WxqfD8WEtHgQWdLqzDi6oEblQY5/uVhvifWmGb7WcMn7+6Iw56G4OVFmh
RJU1HohF+NJ+9+NNmjH7qYbxz5f6zqc87saY2iQBA4P+mfH7LbkHz+midozEyjhd
844g5CPoR/qIcPeEAVBG0rS9qptDpAvLDQcI+y28Ww5iiM5almxv3jQD/+SSNanI
w8lng+WehHcs53fBIqix/ObB39LzJDK9hC0OX4N/OZvcx5juMJm2AKmRpV0uMPBK
tQFaxXL52B4oqwBf+AW9QiD/2bAmT/dH2ccNrWvCGZ3v3+tAzc5MCPBvEj3OgD6y
qSEYCzXMo99RcRmst/EdlTXt761dShkwZkrruDj/8O260Pnhu4ln1TR1+q+SDyZ3
DdDA2z+k55rNq3SJT8JN0hDDOyNLvCYJLeLKt35QILpuUYZFCS/4xPzYDno6U3fP
XbJnyjAs/6IWO4TBMFmOx4SIKnX8w9ACv8LCNyktYfLGBA59UtIe7nnXjudrwRZl
/anp2oOGiQfvbA43LAzI7qqrYNYE1fCUv3Pw98by60VmYnpeQVrbfvD9daQIbEw=
=dfp9
-----END PGP SIGNATURE-----