Re: mod_lets-encrypt

[Dirk-Willem van Gulik]

> On 14 Jan 2017, at 22:31, William A Rowe Jr  wrote:
> 
> On Sat, Jan 14, 2017 at 12:15 PM, Dirk-Willem van Gulik
>  wrote:
>> 
>> On 14 Jan 2017, at 19:05, William A Rowe Jr  wrote:
>> 
>> Any mod_letsencrypt can provision the certs but needs to do so
>> while still root, before servicing requests (although there could be
>> some bounce-step where the MPM begins satisfying requests,
>> including the verification request necessary for letsencrypt.) We
>> certainly don't want to parse any web response whatsoever while
>> running as root.
>> 
>> Some of this will be needed - we need to be root to bind to port 80 — as the
>> protocol (in my reading) seems to demand it (now would be a good time to
>> petition the draft to change this for a random higher port).
>> 
>> In fact - that may be a nice feature - an, essential, empheral port.
> 
> My thinking was more along the lines that we fork off a process, much like
> mod_cgid or mod_ftp does to handle low numbered ports. What is actually
> handed across the domain socket or equivalent is structured simply enough
> to not be harmed by an errant child process, or if needed by the server
> earlier, then forked with the lesser run-as-httpd user permissions to speak
> some predictable and strictly constructed message back up to the root parent
> process.
> 
> It might be nice to our users if the cert/key isn't in the keystore,
> that the server
> starts anyways with a dummy cert, until it finally resolves to the
> letsencrypt CA
> server and completes that handshake.

Technically there is no need from this from a lets-encrypt perspective. Just 
port 80 for a few seconds.

> The server can respond to that child
> process modifying the keystore and exiting by initiating a graceful restart to
> begin serving traffic with the newly obtained cert/key material.

So the process of registering afresh; sending the tokens and getting the certs 
takes seconds at the very most.

So I’d be quite willing to allow a server to not start up an stay in a very 
simple mode prior to this.

An option may be to suid/chroot and what not down - and just hand the child a 
filedescriptor
to which it has write only for just the key - after which it dies.

But fair to assume we can hold of starting the server; it is pretty common to 
see 2-3 seconds
of cycle time due to DNS and what not already.

And anyone who understands/cares can do a dead normal setup using SSL 
thing-a-me’s.

or am I getting the scope wrong ?

> Somewhere in this equation lies accessor functions to mod_ssl to allow us
> access to keystores. Which would be a very useful facility, well beyond just
> letsencrypt. Whether those cert/key pairs live in ldap or some other place.
> Imagine a small cluster, say 4 instances of httpd, where only one performs
> the letsencrypt dance and the others search a memcache or other remote
> resource for the resulting cert/key materials (locked down well, we would
> hope.)

Agreed - but think that this is an ortogonal isue - and have sofar found that
with things like chipcards and HSM - the openssl engines are doing splendidly.

Dw.

Re: mod_lets-encrypt

[Dirk-Willem van Gulik]

> On 14 Jan 2017, at 20:05, Stefan Sperling  wrote:
> 
> On Sat, Jan 14, 2017 at 07:15:29PM +0100, Dirk-Willem van Gulik wrote:
>> In fact - that may be a nice feature - an, essential, empheral port.
> 
> Would that work for web servers behind firewalls?

No; would not expect so. Am willing to declare such more or less out of scope 
for a simple apache module — i.e. if you are in an environment that is that 
‘pro’ that it can do decent firewalls and what not - then running a script like 
dehydrated on cron every 2 weeks to keep your lets-encrypt certs up to date 
should not exactly be beyond you.

But am willing to be convinced that i got the ‘sweet’ spot for this wrong. I am 
amazed by the level of handholding/details people are willing to 
forego/eskew/need in the world of docker containers.

Dw.

Re: mod_lets-encrypt

[William A Rowe Jr]

On Sat, Jan 14, 2017 at 1:05 PM, Stefan Sperling  wrote:
> On Sat, Jan 14, 2017 at 07:15:29PM +0100, Dirk-Willem van Gulik wrote:
>> In fact - that may be a nice feature - an, essential, empheral port.
>
> Would that work for web servers behind firewalls?

Most configured in that scenario need pinholes. I'm not sure that a well
known but non-root port would be considered sufficiently secure by the
letsencrypt architects. Seems worth raising the original question, with
your firewall scenario in mind, and let their architects ponder the idea.

At the end of the day, only the one in control of those firewalls should
be respected by letsencrypt as the owner of the specific domain. That's
why the firewall is in front of their resources in the first place.

Obviously the actual port number isn't a valid security restriction in the
real world in the first place; there are plenty of ways to abuse a front
end firewall/load balancer behind the lines, and many appliances and
OS's don't require root or can be configured to permissively let other
accounts listen on particular low ports, and as long as you are physically
able to access the cables... but letsencrypt is not concerned with that.
It's simply that they are able to validate that you are in some way in control
of the target of the corresponding DNS A or  records.

Re: mod_lets-encrypt

[William A Rowe Jr]

On Sat, Jan 14, 2017 at 12:15 PM, Dirk-Willem van Gulik
 wrote:
>
> On 14 Jan 2017, at 19:05, William A Rowe Jr  wrote:
>
> Any mod_letsencrypt can provision the certs but needs to do so
> while still root, before servicing requests (although there could be
> some bounce-step where the MPM begins satisfying requests,
> including the verification request necessary for letsencrypt.) We
> certainly don't want to parse any web response whatsoever while
> running as root.
>
> Some of this will be needed - we need to be root to bind to port 80 — as the
> protocol (in my reading) seems to demand it (now would be a good time to
> petition the draft to change this for a random higher port).
>
> In fact - that may be a nice feature - an, essential, empheral port.

My thinking was more along the lines that we fork off a process, much like
mod_cgid or mod_ftp does to handle low numbered ports. What is actually
handed across the domain socket or equivalent is structured simply enough
to not be harmed by an errant child process, or if needed by the server
earlier, then forked with the lesser run-as-httpd user permissions to speak
some predictable and strictly constructed message back up to the root parent
process.

It might be nice to our users if the cert/key isn't in the keystore,
that the server
starts anyways with a dummy cert, until it finally resolves to the
letsencrypt CA
server and completes that handshake. The server can respond to that child
process modifying the keystore and exiting by initiating a graceful restart to
begin serving traffic with the newly obtained cert/key material.

Somewhere in this equation lies accessor functions to mod_ssl to allow us
access to keystores. Which would be a very useful facility, well beyond just
letsencrypt. Whether those cert/key pairs live in ldap or some other place.
Imagine a small cluster, say 4 instances of httpd, where only one performs
the letsencrypt dance and the others search a memcache or other remote
resource for the resulting cert/key materials (locked down well, we would
hope.)

Re: mod_lets-encrypt

[Stefan Sperling]

On Sat, Jan 14, 2017 at 07:15:29PM +0100, Dirk-Willem van Gulik wrote:
> In fact - that may be a nice feature - an, essential, empheral port.

Would that work for web servers behind firewalls?

Re: mod_lets-encrypt

[Dirk-Willem van Gulik]

> On 14 Jan 2017, at 19:05, William A Rowe Jr  wrote:
> 
> On Sat, Jan 14, 2017 at 10:22 AM, Eric Covener  wrote:
>> On Sat, Jan 14, 2017 at 11:19 AM, Eric Covener  wrote:
>>> 
>>> I think if a feature/directive will turn on something that will write
>>> to configured keystores, it really shouldn't do or dictate much else.
>> 
>> Poorly phrased, but I think obtaining a cert should be separate from
>> things like further SSL configuration.
> 
> I think Dirk is suggesting that the core mod_ssl continues to exist, with
> sane defaults that require next to no specific directives other than to
> perhaps set the https protocol on port 443, and (I vote optionally) have
> a one line toggle for rewriting all port 80 requests to 443.
> 
> Note that h2 requests will continue to be honored on either port 80
> or 443, so this has to be crafted somewhat carefully.
> 
> I'm 100% in support of ensuring that mod_ssl runs with the most
> sensible choices in the most minimal config.
> 
> Any mod_letsencrypt can provision the certs but needs to do so
> while still root, before servicing requests (although there could be
> some bounce-step where the MPM begins satisfying requests,
> including the verification request necessary for letsencrypt.) We
> certainly don't want to parse any web response whatsoever while
> running as root.

Some of this will be needed - we need to be root to bind to port 80 — as the 
protocol (in my reading) seems to demand it (now would be a good time to 
petition the draft to change this for a random higher port).

In fact - that may be a nice feature - an, essential, empheral port.

And we will need to be able to respond to an HTTP request to a well known URL 
with the public key/token — and post that have some fork/pid be root enough to 
write a few things to safe places.

> I do believe the proposal should require a one line directive to
> enable this, particularly for the compiled-in static many modules
> build of httpd. It's shouldn't be simply a matter of loading some
> mod_letsencrypt without also some 'LetsEncrypt on" directive
> in the ssl vhost config.

The alternative is bundling a small shell script, like  stripped down
‘dehydrate’:

https://github.com/lukas2511/dehydrated/blob/master/dehydrated 


as a tool. And augment it with examples. But then you are back to square one.

Dw.

Re: mod_lets-encrypt

[William A Rowe Jr]

On Sat, Jan 14, 2017 at 10:22 AM, Eric Covener  wrote:
> On Sat, Jan 14, 2017 at 11:19 AM, Eric Covener  wrote:
>>
>> I think if a feature/directive will turn on something that will write
>> to configured keystores, it really shouldn't do or dictate much else.
>
> Poorly phrased, but I think obtaining a cert should be separate from
> things like further SSL configuration.

I think Dirk is suggesting that the core mod_ssl continues to exist, with
sane defaults that require next to no specific directives other than to
perhaps set the https protocol on port 443, and (I vote optionally) have
a one line toggle for rewriting all port 80 requests to 443.

Note that h2 requests will continue to be honored on either port 80
or 443, so this has to be crafted somewhat carefully.

I'm 100% in support of ensuring that mod_ssl runs with the most
sensible choices in the most minimal config.

Any mod_letsencrypt can provision the certs but needs to do so
while still root, before servicing requests (although there could be
some bounce-step where the MPM begins satisfying requests,
including the verification request necessary for letsencrypt.) We
certainly don't want to parse any web response whatsoever while
running as root.

I do believe the proposal should require a one line directive to
enable this, particularly for the compiled-in static many modules
build of httpd. It's shouldn't be simply a matter of loading some
mod_letsencrypt without also some 'LetsEncrypt on" directive
in the ssl vhost config.

Re: mod_lets-encrypt

[Eric Covener]

On Sat, Jan 14, 2017 at 11:19 AM, Eric Covener  wrote:
>
> I think if a feature/directive will turn on something that will write
> to configured keystores, it really shouldn't do or dictate much else.

Poorly phrased, but I think obtaining a cert should be separate from
things like further SSL configuration.

-- 
Eric Covener
cove...@gmail.com

Re: mod_lets-encrypt

[Eric Covener]

On Sat, Jan 14, 2017 at 10:43 AM, Dirk-Willem van Gulik
 wrote:
>
> Where this implies SSLEnable, a set of sane/best-practice. ‘A+’, set of
> baseline SSL directives w.r.t. OSCP stapling  and so on. And absolutely no
> further SSL statements in your vhost. And it implies that port 80 forwards
> to https. Perhaps disallow any port/listen stuff ?
>
> If you need SSL statements — then you are out of scope ? Is that fair ?

I think if a feature/directive will turn on something that will write
to configured keystores, it really shouldn't do or dictate much else.


-- 
Eric Covener
cove...@gmail.com

Re: mod_lets-encrypt

[Dirk-Willem van Gulik]

(reshuffled top post)

On 14 Jan 2017, at 16:07, Rich Bowen  wrote:
> On Jan 10, 2017 12:15 PM, "Jacob Champion"  > wrote:
> On 01/10/2017 08:35 AM, Dirk-Willem van Gulik wrote:
> Before I send someone into the woods - did anyone consider/do a quick
> ‘mod_lets_encrypt’ (with or without a persistent store) — that
> requires virtually no configuration ?
> 
> Considered? Yes. Back in August there was some discussion on this list with 
> Josh Aas. I don't know what the current status is.
..
> https://lists.apache.org/thread.html/ea902ae8e453b3a8d36345318fc74a54880d8bf14fed24e665c4b833@%3Cdev.httpd.apache.org%3E
>  
> 
...
> https://lists.apache.org/thread.html/27d1fce7d30d9e31e2472045c260e4f8dcefd300a731ff9e435a5d4a@%3Cdev.httpd.apache.org%3E
>  
> 
> I talked with him at linuxcon, but there's been no followup. I for one would 
> love to see this happen.

So it seems we currently pull in enough sundry into mod_ssl to barely need 
something as ‘big’ as:

https://github.com/kristapsdz/acme-client 

if we assume the HTTP method (only) — which makes sense if we assume that this 
module is first and foremost about zero configuration and convenience. 

By extend that also means we ‘trust’ ourselves and the user we start up as 
(prior to any fork, suid or chrooting).

So I think we can narrow this down a lot (I just had to put something like this 
into a simple XMPP system) - as anyone who wants to do something more complex 
can use the many scripts available or use ‘real’ CA request processes.

So we are talking about the configs which are as simple as

# Defaults to /var/httpd/acme-private or something like we do for 
Mutexes.
#
ACMEDir /var/db/httpd/acme-private


ACME automatic
…

Where this implies SSLEnable, a set of sane/best-practice. ‘A+’, set of 
baseline SSL directives w.r.t. OSCP stapling  and so on. And absolutely no 
further SSL statements in your vhost. And it implies that port 80 forwards to 
https. Perhaps disallow any port/listen stuff ?

If you need SSL statements — then you are out of scope ? Is that fair ?

Which reduces the footprint to:

-   fetching the ACME-CA-URLs on first run ever; on install —or— having 
these as part of the distribution.

=> Fair to assume we ship with the ACME CA url ?

-   pin the server.

-   reading -or- generating an RSA key & 0600 storing it in what we 
consider a safe enough place (prior to any chroot)ing. 

=> Fair to assume key rollover is out of scope for this key (we could 
even do this empheral - and regenerate on renewal) ?

=> Fair to assume we just use one for all domains ?

-   Register this on first run. 

=>  Fair to assume things like contact email and EULA ok are out of 
scope ?

-   Build up a cert for each vhost; with all aliases added too as altnames. 

- for each vhost (altname) — get a challenge from the ACME server.

=>  Fair to assume we do not care about account recovery ?

-   bring up that/all vhost on their port 80  (all vhosts that have 
LetsEncrypt set to auto/on).

=> so if I understand the spec right - only port 80

==>  thus fair to assume non-root startup is out of 
scope - as we need to bind to a port < 1024.

So therefore:
=> fair to configure this ‘easier’ — i.e. if you do 
LetsEnrypt on on a domain SSL auto switches on and port 80 becomes an automatic 
redirect to https ?

-   Respond to the well know URI with each of he challenges.

-   Fetch/poll for the cert; save with 0600 and tight UID and be done.

-   Gracefully fail for each domain after N seconds - blocking https and 
with a sorry no ACME on http.

=>  do we need to allow for an ErrorDocument customisation of the 
latter ?

-   Set up a sane virtual SSL set of directives; and then chroot/suid/fork 
and start your normal run.

-   Switch of http or make http a blind to https forwarder.

-   Can we assume that the server has a graceful restart every week ? 

=> And thus declare ACME renewal from within out of scope  ?

Or do we need to auto disable SSL and go to http ?

Does that make sense - or have I oversimplified it and lost the plot ?

Dw

Re: mod_lets-encrypt

[Rich Bowen]

I talked with him at linuxcon, but there's been no followup. I for one
would love to see this happen.

On Jan 10, 2017 12:15 PM, "Jacob Champion"  wrote:

> On 01/10/2017 08:35 AM, Dirk-Willem van Gulik wrote:
>
>> Before I send someone into the woods - did anyone consider/do a quick
>> ‘mod_lets_encrypt’ (with or without a persistent store) — that
>> requires virtually no configuration ?
>>
>
> Considered? Yes. Back in August there was some discussion on this list
> with Josh Aas. I don't know what the current status is.
>
> See
>
>
> https://lists.apache.org/thread.html/ea902ae8e453b3a8d363453
> 18fc74a54880d8bf14fed24e665c4b833@%3Cdev.httpd.apache.org%3E
>
> and
>
>
> https://lists.apache.org/thread.html/27d1fce7d30d9e31e247204
> 5c260e4f8dcefd300a731ff9e435a5d4a@%3Cdev.httpd.apache.org%3E
>
> --Jacob
>

Re: mod_lets-encrypt

[Jacob Champion]

On 01/10/2017 08:35 AM, Dirk-Willem van Gulik wrote:

Before I send someone into the woods - did anyone consider/do a quick
‘mod_lets_encrypt’ (with or without a persistent store) — that
requires virtually no configuration ?


Considered? Yes. Back in August there was some discussion on this list 
with Josh Aas. I don't know what the current status is.


See


https://lists.apache.org/thread.html/ea902ae8e453b3a8d36345318fc74a54880d8bf14fed24e665c4b833@%3Cdev.httpd.apache.org%3E

and


https://lists.apache.org/thread.html/27d1fce7d30d9e31e2472045c260e4f8dcefd300a731ff9e435a5d4a@%3Cdev.httpd.apache.org%3E

--Jacob

mod_lets-encrypt

[Dirk-Willem van Gulik]

Before I send someone into the woods - did anyone consider/do a quick 
‘mod_lets_encrypt’ (with or without a persistent store) — that requires 
virtually no configuration ?

Or is the web world still thinking unix with clear small concise scripts that 
do one thing well ?

Dw