[Acme] Security concerns with “http-01” and “tls-sni-01"

Thomas Lußnig <lussnig@suche.org> Mon, 16 November 2015 21:59 UTC

Return-Path: <lussnig@suche.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 31D801B31FE for <acme@ietfa.amsl.com>; Mon, 16 Nov 2015 13:59:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.75
X-Spam-Level:
X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 GkRRNrW3SSEq for <acme@ietfa.amsl.com>; Mon, 16 Nov 2015 13:59:35 -0800 (PST)
Received: from relay-mx.smcc.de (relay-mx.smcc.de [194.50.33.90]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 655711B3202 for <acme@ietf.org>; Mon, 16 Nov 2015 13:59:35 -0800 (PST)
Received: by mx-32.smcc.de (Postfix, from userid 65534) id C96895654F; Mon, 16 Nov 2015 22:59:33 +0100 (CET)
X-Spam-SCL: 1
Received: from localhost (localhost [127.0.0.1]) by mx-32.smcc.de (Postfix) with ESMTP id 1AA535654E for <acme@ietf.org>; Mon, 16 Nov 2015 22:59:33 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mx-30.smcc.net
Received: from relay-mx.smcc.de ([127.0.0.1]) by localhost (relay-mx-02.smcc.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSZXnnt-J-Jk for <acme@ietf.org>; Mon, 16 Nov 2015 22:59:33 +0100 (CET)
Received: from [192.168.1.3] (ip-81-210-219-184.hsi17.unitymediagroup.de [81.210.219.184]) by mx-32.smcc.de (Postfix) with ESMTPSA id EC0595654C for <acme@ietf.org>; Mon, 16 Nov 2015 22:59:32 +0100 (CET)
To: acme@ietf.org
References: <mailman.0.1447710932.32014.acme@ietf.org>
From: Thomas Lußnig <lussnig@suche.org>
Message-ID: <564A51C6.7070309@suche.org>
Date: Mon, 16 Nov 2015 22:59:34 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:43.0) Gecko/20100101 Thunderbird/43.0a2
MIME-Version: 1.0
In-Reply-To: <mailman.0.1447710932.32014.acme@ietf.org>
Content-Type: multipart/alternative; boundary="------------010807050907080206040804"
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/FLKC5tlsl8G2f3JU59dYDVXtzhI>
Subject: [Acme] Security concerns with “http-01” and “tls-sni-01"
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, 16 Nov 2015 22:12:13 -0000

Hi,

i have some security concerns with both methods:
- http-01 here the server only show that he know the public key of the 
client. Token + Hash(publicUserKey)
At least the server have the information for which domain he is proving.
- tls-sni-01 here the only task is that the server have to reply with 
and certificate with specified subjectAlternativeName
..acme.invalid

The simpleHTTP not only check that the server handle the domain, it also 
checked that the server knows the privateUserKey so why not using 
simpleHTTP via HTTP if there are HTTPS-Concerns about stupid admin with 
default Servers?

Option 1)

For tls-sni we could request ...acme.invalid
And the server response should contain two alternative names.

...acme.invalid
encoded(SHA1withRSA(...acme.invalid , userKey)).SHA1withRSA.acme.invalid
So he proves that he have ht private user key and he know for which 
domain he is proving:

Option 2)
signature = HEX(SHA1withRSA(fqdn|'.'|token, userKey))
http := http:///.well-known/acme-challenge//
Reply: text/plain ,

tls-sni: ...acme.invalid
Reply: SubjectAlternativeName: ...acme.invalid

So in this case the server does not require to have access to the 
private user key.
He only need access to the public key but than can verify that the 
request was issued by some person who have the users private key. That 
mean we have an two way identification.
---
Example for tls-sni-01 problem:

I will explain it for tls-sni-01.
1) You have an HTTPS Server that will response to any SNI with an 
Matching Selfsigned Certificate.
- This is used for debuging or for example for some types of fw devices 
that use non official CA's.
This Device also Host the domain www.interesting-bank.com 
<http://www.interesting-bank.com>
2) Now i as an attacker place an request for "www.interesting-bank.com" 
and select "tls-sni-01" challenge.
LE will now connect to the ip for "www.interesting-bank.com" and say 
hostnameInfo ..acme.invalid
3) The returned certificate will contain ..acme.invalid (Challenge OK)
4) Know i can request Cert for "www.interesting-bank.com" and was never 
in hold or had access to the server www.interesting-bank.com 
<http://www.interesting-bank.com>.

---

More about this problem and discussions can be found under 
https://community.letsencrypt.org/t/getting-bad-vibes/3424/72

Gruß Thomas