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

[Ilari Liusvaara <[e-mail]>]

On Sun, Jan 15, 2017 at 05:59:43PM +0100, Dirk-Willem van Gulik wrote:
> 
> 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.

There's also the fact that HTTP-01 will follow redirects to https://
(just the initial request has to be http://), ignoring certificate
validity.

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

The funny ports are because one can't get enough IPv4 address space
to give each container its own address?

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

Well, if the port 80 on the same external IP could be configured to serve
a redirect to https for validation requests (which is just a static
mapping per FQDN), then those requests would presumably be sent to the
container.

That is, rule of form: http://foo.example/.well-known/acme-challenge/bar
-> https://foo.example/.well-known/acme-challenge/bar 

And the secondary requests also AFAIK have SNI on TLS level, so one can
route on that too.


-Ilari