Re: Certificate error on php.net
| From: | Ryan Mauger | Date: | Tue, 23 Jun 2015 18:18:58 +0000 |
| Subject: | Re: Certificate error on php.net | ||
| References: | 1 2 3 4 5 6 7 8 9 | Groups: | php.webmaster |
| Request: | Send a blank email to php-webmaster+get-21417@lists.php.net to get a copy of this message | ||
I wasn't actually trying to achieve anything by visiting the downloads in
https (I was actually visiting the release notes when it happened, not the
downloads).
The overall movement by browsers at the moment considering the current
climate is to push for https being used more universally, and I feel this
is actually a positive step for progress, which is why I use the EFF's
HTTPSEverywhere plugin in my browser.
The use of md5 in 2015 is honestly a bad idea imo, given that people
everywhere are pushing for people to stop using md5 in any security related
context, and that since 2006 its been possible to generate collisions on
the algorithm in minutes on only a notebook computer, it really should be
consigned to the history books.
The sha256, while better, still is not fantastic, considering that the
php.net site appears to also be running from those mirrors (I was on the
php.net domain, and not a subdomain of it when I got the certificate
error), which would make it possible for a mirror which has been
compromised to also change the apparent checksum to simply match the one
they are distributing.
The GPG signing, is indeed the correct method to use, I have no bones with
that, I would however be surprised if you looked in your logs and found
anything close to a 1:1 ratio of downloads of the sources to downloads of
the signature. or any ratio which would suggest it was a common practice,
so https in some part, would at least protect anyone using automated tools
from man-in-the-middle.
The lack of any documentation of how to actually verify the GPG signature
also now occurs to me as being missing, and it would be great to see that
added to the docs on at least the downloads page, if not also the pages
concerned with compiling PHP.
As far as suggestions go
- Move the mirrors into their own domain (phpmirrors.org?) or subdomain (
mirrors.php.net) preferably not actually on the php.net domain, as then
a compromise of the keys for the mirrors domain does not automatically
extend to php.net
- Talk to services such as Cloudflare, they may be open to supporting
PHP with some sponsorship?
- Give each of the mirrors their own certificate when letsencrypt
becomes a reality later this year (assuming they get the OS / Browser
support across the board)
- Consider pooling mirrors into groups, using multiple certificates, and
sharing one set of keys across smaller sets of mirrors at once, so not all
mirrors and php.net itself share the same keys
On Tue, 23 Jun 2015 at 18:04 Hannes Magnusson <hannes.magnusson@gmail.com>
wrote:
> On Tue, Jun 23, 2015 at 9:55 AM, Kalle Sommer Nielsen <kalle@php.net>
> wrote:
> > 2015-06-23 18:34 GMT+02:00 Hannes Magnusson <hannes.magnusson@gmail.com
> >:
> >> What binaries? Someone is playing you for a fool if you are seeing
> >> binaries on www.php.net or the mirrors. We do not distribute binaries.
> >
> > I think he meant the Windows binaries, although they are from
> > *windows*.php.net and distributed from Microsoft mirrors.
>
>
> The Windows downloads aren't even signed, which provides a different
> set of problems alltogether - but has nothing to do with the initial
> problem; browsing www.php.net over https :/
>
> -Hannes
>