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). 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.

> 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).


[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.


-Ilari

_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme

Reply via email to