Re: HTTPS support for geo DNS mirrors

On Wed, Aug 19, 2015 at 11:22 PM, Patrick Schaaf <[email protected]> wrote:
> Am 20.08.2015 02:17 schrieb "Rasmus Lerdorf" <[email protected]>:
>>
>> We obviously can't distribute the private key for out wildcard *.php.net
>> cert out to every mirror, but maybe we should consider writing something
>> that could generate per-mirror certs for mirrors to get around this
>> problem
>
> I don't think per-mirror certs, _if_ the geodns thing for www.php.net could
> be made the only way to access the mirrors - i.e. the cc1.php.net names
> could be ignored.
>
> The whole thing would need an automated way to push new keys to the mirrors
> anyway. What would then be more important, wrt mirrors being faded,
> misbehaving, or having their key stolen, would be to have certificates with
> rather short expiry, like a week or a month.
>
> With the usual long certificate expiry, and certificate revocation not
> really working (right?), a rogue mirror or victim of a breakin would
> compromise the whole setup for a long time.


We are acutely aware of the problems. If you have a concrete
suggestion on what we can to resolve this, we'd love the help.
Like I said, at the moment all we are doing is waiting to see what
comes out of letsencrypt.org, which appears to be able to resolve many
of these things: https://letsencrypt.org/howitworks/

We might be able to generate multiple www.php.net cert (with
ccX.php.net and cc.php.net as secondary names), per mirror, with a
short expiry. When a mirror is automatically disabled we could revoke
the cert. When a mirror is enabled, we could generate a new one.

How to transfer the certificate to its destination automatically would
then be the tricky part. Mirror maintainers might need to update their
cron from being standalone rsync command, to possibly needing to run a
10line shell/php script to fetch the certificate somehow encrypted and
privately.. I don't know. I don't know how letsencrypt.org will work
in practice or what alternative problems that will bring -- but at
this time, it is the only idea I've got and am waiting for a chance to
play with it.


>> and have the config either redirect to non-https or to
>> https://secure.php.net
>
> Hmm. If a good solution to the key distribution were in place, what would
> stop us from running the normal site access through https, only redirecting
> critical stuff that needs to be on central sites?


Nothing. Thats why that was a "or [if that is not possible], we
redirect to secure.php.net". But we haven't been able to come up with
a configuration the would be able to do this.


Today, we cannot offer https://www.php.net for the reasons we are all
aware of (if it hits mirror, it doesn't have the certificate). The
current workaround for that is, because we do want to be able to
provide atleast minimal https experience to people that require it, is
to send those to https://secure.php.net -- which is just one server
under our control.

If we figureout a why to run www.php.net over https, secure.php.net
will be around for few months/years as a legacy service, likely just
redirecting to www.php.net.

This is the best we can offer at the moment until someone gets a
cartoon figured lightbulb containing the solution :(

-Hannes