[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-----
- [Acme] Validation Vulnerabilities moparisthebest
- Re: [Acme] Validation Vulnerabilities Salz, Rich
- Re: [Acme] Validation Vulnerabilities Richard Barnes