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

[Dirk-Willem van Gulik <[e-mail]>]

> On 15 Jan 2017, at 18:36, Ilari Liusvaara <[e-mail]> wrote:
> 
> 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.

That is indeed the alternative — surmise that as the user (no matter how VM’s, containers, virtual load balancers or whatever is configured) will want to end up visible on port 443 with a cert — we focus on some blind http->https redirect which can be configured in bulk; and always bring up an TLS+SSL on 443 with a self signed cert if we do not yet have an acme cert (and using the same private key for thus).

Dw.