Re: [Acme] Well Known CA->client poll on port 80/443 in http-acme

Dirk-Willem van Gulik <dirkx@webweaving.org> Sun, 15 January 2017 17:01 UTC

Return-Path: <dirkx@webweaving.org>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A27C12960C for <acme@ietfa.amsl.com>; Sun, 15 Jan 2017 09:01:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.199
X-Spam-Level:
X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 tNGSOfIscgpA for <acme@ietfa.amsl.com>; Sun, 15 Jan 2017 09:01:19 -0800 (PST)
Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94B91294CC for <acme@ietf.org>; Sun, 15 Jan 2017 09:01:18 -0800 (PST)
Received: from beeb.leiden.webweaving.org (5ED06D14.cm-7-1b.dynamic.ziggo.nl [94.208.109.20]) (authenticated bits=0) by weser.webweaving.org (8.15.2/8.15.2) with ESMTPSA id v0FGximI049299 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 15 Jan 2017 18:00:00 +0100 (CET) (envelope-from dirkx@webweaving.org)
X-Authentication-Warning: weser.webweaving.org: Host 5ED06D14.cm-7-1b.dynamic.ziggo.nl [94.208.109.20] claimed to be beeb.leiden.webweaving.org
From: Dirk-Willem van Gulik <dirkx@webweaving.org>
Message-Id: <CD5EBC6C-456C-4A08-AE98-4166F2270E77@webweaving.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_452831EF-6D2F-4977-8457-F622091584CF"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Sun, 15 Jan 2017 17:59:43 +0100
In-Reply-To: <20170115150407.GA26702@LK-Perkele-V2.elisa-laajakaista.fi>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
References: <9099A621-D460-47B6-9172-0984CF3A0DC8@webweaving.org> <20170115140330.GA26429@LK-Perkele-V2.elisa-laajakaista.fi> <6AEBC4C9-FA1B-4672-AE58-15C165722B30@webweaving.org> <20170115142931.GB26429@LK-Perkele-V2.elisa-laajakaista.fi> <65DAC165-2700-4DA5-A492-28B1F2E60541@webweaving.org> <20170115150407.GA26702@LK-Perkele-V2.elisa-laajakaista.fi>
X-Mailer: Apple Mail (2.3259)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (weser.webweaving.org [148.251.234.232]); Sun, 15 Jan 2017 18:00:00 +0100 (CET)
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/1mH0vCfmzUOAsJ_jUQtxucN1iz8>
Cc: acme@ietf.org
Subject: Re: [Acme] Well Known CA->client poll on port 80/443 in http-acme
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.17
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: Sun, 15 Jan 2017 17:01:20 -0000

> On 15 Jan 2017, at 16:04, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
> 
> On Sun, Jan 15, 2017 at 03:39:43PM +0100, Dirk-Willem van Gulik wrote:
>> 
>>> On 15 Jan 2017, at 15:29, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
>>> 
>>> There actually are restrictions on what ports public CAs can use for
>>> authentication. These are:
>>> 
>>> - 80 (HTTP)
>>> - 443 (HTTPS)
>>> - 115 (SFTP; no, not _that_ SFTP [1])
>>> - 25 (SMTP)
>>> - 22 (SSH)
>>> 
>>> These limits are exactly so that unprivileged users don't bind
>>> daemons to the ports and use those to obtain certificates (the
>>> certificates are valid for all ports).
>> 
>> Just to make sure I understand the reasoning:
>> 
>> CA Policy prohibits an ACME CA Server from fetching the token
>> (authenticating) from a subscriber port > 1024 (or a port not an
>> element of [80,443,115,25,22)) because an (on common  flavours of
>> unix) an un(der)privileged) user may run a daemon on such a port.
>> 
>> Correct ? Just so I understand the tradeoffs made correctly when
>> implementing/mitigating the root-risk on the webserver side.
> 
> Actually, ACME as of currently can use only 80 or 443 (there is
> no explicit port selection anywhere).

Which makes sense given the current CABForum limitation.

> The remaining three ports
> might be used by  non-ACME public CAs.
> 
> And all those five ports are privileged to bind to (but once
> bound, are not privileged to accept connections from[2]). And if
> you are talking about abuse from root, there is not much that
> can be done, outside Mandatory Access Control extensions like
> SELinux and such.

Agreed - I am more concerned about the opposite - allowing well intending non-root users who want to spin up a server to do the right thing.

The more educated/capable group is already well served by, for example, a trivial apache SSL config file  in conjunction with shell scripts [1,2].

>> You would not happen to know where these are documented (I’ve
>> scanned CPS, SA and policy but no cookie yet).
> 
> CABForum Baseline Requirements.(I looked up version 1.3.9, since
> the 1.4 versions are AFAIK essentially withdrawn).

Lovely - thanks!

> [2] It is actually possible to bind to such port, drop privileges
> and then pass the descriptor to another program via exec or even
> local socket. The receiver can then accept connections from it,
> even if receiver never was privileged. I have one daemon on one VM
> that does just that with port 443.
``
We have sufficient infrastructure for that in apache and its APR utility library.

I am trying to understand enough of the considerations of ACME (such as the choise for the the ‘Authorized Ports’ list as defined in that CABForum BR) to help me make the right trade offs between a) bringing the webserver up in a relatively insecure fashion for a short period of time and getting the business of (re)new cert’s over as robustly as possible v.s. spinning up much more surface of things that can confuse -or- go wrong (including apache its normal devolved setuid()/chroot() post forking & opening the < 1024 sockets), are expensive to maintain or prone to abuse.

And secondly I am trying to come to grips with the advent of virtualisation & containerisation causing the concepts of virtual hosts to change; rather than have 10’s of thousands of VHOSTs in a single config/binary; all listening to all IP’s on port 80 - so common at the turn of the century - one now  increasingly sees a lot of port mapping - where in effect each httpd runs ‘alone’, in a container, with a single vhost config - albeit on a funny port. 

Which may, or may not be, mapped to some IP:80 or through some LB/fan-out proxy that has a FQDN->internal IP & port table. Software defined networking seems to favour the latter.

But the net effect is that that makes the listening on port 80 for a FQDN that is elsewhere configured to be visible on just a single IP:443 (mapped to -> internal-ip + high port) rather much out of reach. As a listen *:80 is no longer effective. Especially for the cohort of users for whom the scripting is already out of reach.

Hence the desire to understand the design better.

Thanks,

Dw.

1: https://github.com/Neilpang/acme.sh <https://github.com/Neilpang/acme.sh>
2: https://github.com/lukas2511/dehydrated <https://github.com/lukas2511/dehydrated>