[Acme] Stronger protection against HTTPS MITM

Mateusz Jończyk <mat.jonczyk@o2.pl> Sun, 25 January 2015 08:59 UTC

Return-Path: <mat.jonczyk@o2.pl>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 6B8701A7015 for <acme@ietfa.amsl.com>; Sun, 25 Jan 2015 00:59:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.185
X-Spam-Level: ****
X-Spam-Status: No, score=4.185 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id xSB5eJPSIfLy for <acme@ietfa.amsl.com>; Sun, 25 Jan 2015 00:59:54 -0800 (PST)
Received: from moh1-ve1.go2.pl (moh1-ve1.go2.pl []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D0131A0143 for <acme@ietf.org>; Sun, 25 Jan 2015 00:59:54 -0800 (PST)
Received: from moh1-ve1.go2.pl (unknown []) by moh1-ve1.go2.pl (Postfix) with ESMTP id BD24491DEE0 for <acme@ietf.org>; Sun, 25 Jan 2015 09:59:52 +0100 (CET)
Received: from unknown (unknown []) by moh1-ve1.go2.pl (Postfix) with SMTP for <acme@ietf.org>; Sun, 25 Jan 2015 09:59:51 +0100 (CET)
Received: from bbs4.neoplus.adsl.tpnet.pl [] by poczta.o2.pl with ESMTP id GIKbXf; Sun, 25 Jan 2015 09:59:51 +0100
Message-ID: <54C4B086.5080005@o2.pl>
Date: Sun, 25 Jan 2015 09:59:50 +0100
From: Mateusz Jończyk <mat.jonczyk@o2.pl>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: acme@ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-O2-Trust: 2, 68
X-O2-SPF: notchecked
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/BjTQFgkW516gwHU3Xr_LtnRTL_A>
Subject: [Acme] Stronger protection against HTTPS MITM
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: Sun, 25 Jan 2015 08:59:55 -0000

Suppose that Bob (admin of www.example.com) wants to get a signed certificate
for that domain and Eve (from NSA) is trying to get that certificate too. Eve
can also somehow do HTTPS MITM en route from Bob's computer to the ACME server
(I will ignore here the possibility of HTTPS MITM en route from the ACME server
to Bob's server). To make it more realistic [1], let's also suppose that Bob has
received a signed certificate for www.example.com in the past so that the
validation process involves PoP of previous key / recovery token.

In that case and with current ACME spec [2], Eve can AFAIK get a separate signed
certificate without any knowledge of Bob (unless he has access to reliable
public cert issuance records and inspects them). To do this, she could pass
through all validation challenges while substituting her own (independently
generated) public key. The ACME server will then happily validate Eve for
www.example.com and sign her key.

Then, after Eve got her certificate, she could send some error message to Bob,
such as "The server is overloaded. Please try again in 5 minutes". To make it
more realistic, she may send a defer message with a long timeout to Bob before
that. Bob (or even an automatic script) will then ask for the signature again
and get it unobstructed.

To block such an attack, all challenge responses should depend somehow on the
public and/or private keys of Bob. For example, in the "simpleHttps" method, the
value provisioned in the file should be signed with Bob's private key.
Alternatively, some time delay between two certificate issuances for
www.example.com could be enforced (e.g. 24 hours). If Bob would have to wait
that long, he would have begun to wonder what was going on.

Also, the Recovery Token that is sent from the ACME server should be encrypted
with Bob's private key so that Eve could not use it later to get a separate cert.


[1] Because otherwise almost any Eve that could do MITM can also redirect all
trafic from ACME server to www.example.com and get a cert that way.

[2] I meant last version of