> On 15 Jan 2017, at 16:04, Ilari Liusvaara <[email protected]> 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 <[email protected]> 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>
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
