The Heartbleed bug was a reminder that permanently inside the address space of the SSL terminator is the private key for that service. It is a high-value target.
In the interests of reducing the attack space against SSL terminators, I suggest keeping them in a separate address space from applications -- either by proxying or by CGI/FastCGI. Obviously for the main site, we are doing that already, but at least for blog.wikimedia.org and ticket.wikimedia.org we are not.
On Thu, Apr 10, 2014 at 10:51:38PM +0000, Tim Starling via RT wrote:
The Heartbleed bug was a reminder that permanently inside the address space of
the SSL terminator is the private key for that service. It is a high-value
target.In the interests of reducing the attack space against SSL terminators, I
suggest keeping them in a separate address space from applications -- either by
proxying or by CGI/FastCGI. Obviously for the main site, we are doing that
already, but at least for blog.wikimedia.org and ticket.wikimedia.org we are
not.
What we are generally doing is pushing more services behind the
misc-web-lb Varnish (and SSL termination) cluster. This happened
extensively the past three months and various services have been
migrated and new services have gone there by default.
We don't have 100% of misc services there yet and there are some
services for which we explicitly don't /want/ to put behind this cluster
(think Icinga and similar tools).
For these, we have issued one-off certificates that have only their
hostname in CN/SAN. Therefore, there is no wildcard certificate that is
exposed in the way you described, as the only wildcards are on the main
cluster (the multi-domain-wildcard one) and the misc cluster (a
*.wikimedia.org certificate). This isn't contradicting your statement of
course, but it's worth pointing out that it does reduce the value of
those targets (= you can hack the blog, and gain the ability to
impersonate just the blog).
blog.wikimedia.org is already behind a separate Varnish instance and
hence can be easily migrated to misc-web-lb, however we've decided to
not do that as the blog is supposed to be outsourced to a third-party
company RSN and isn't worth our time.
I don't see a reason why ticket.wikimedia.org couldn't be moved behind
misc-web-lb. We should probably do that. I'm sure there are others like
it, some of which are unmaintained too (e.g. contacts.wikimedia.org). We
should do another pass on the full certificate list and move more
services behind misc-web-lb.
Faidon
Im going to boldly close this, i think the infrastructure has moved on significantly from this so im not sure the task is still valid but please re-open and update if you disagree