[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
- [Acme] Security concerns with “http-01” and “tls-… Thomas Lußnig