On 04/14/2012 10:59 AM, Dennis E. Hamilton wrote:
Kay, thanks for noticing the security issue around having a script
served from an insecure web page.
Well...my concern didn't really stem from the security of the
openoffice.org "site" but other issues...mostly I got to thinking about
how we do things now -- manually changing download services vs maybe a
more automatic way to deal with this. And, perhaps this would be a way
for us to continue to include MirroBrain as well as SourceForge and the
Apache mirrors in the download process with minimal effort.
That has me thinking about the security context for server-side
selection of mirrors (assuming that the server sends confirmed
redirects back to the requester),
I think the URL to request the download has to resolve to an
apache.org location where the mirror site selection and
forwarding/redirection then happens. (an openoffice.org location in
ASF custody would work as well).
yes, this is a desired goal I think...
So now whatever the mirror-selection procedure is, it is on the
server and at least read-only (if not inaccessible completely). (The
link in the browser page can still be hacked, of course, so it would
be good to add some protection in depth at that point of weakness.)
OK...more good points
In addition, the digest values used to confirm the authenticity and
integrity of downloads must not be on the mirror sites. They must be
in a secured, read-only place that exists entirely in ASF custody.
Because digests are not authentication codes (MACs) protected by
private keys, the only way they are trustworthy is if they are
protected separately and in a unique read-only place where injection
of forgeries is (1) extremely difficult and (2) readily detected and
repaired. To impede man-in-the-middle situations, this must also be
a site that requires TLS (i.e., SSL) access and might be in a very
small, narrowly-used subdomain that only that SSL certificate is
usable with.
Since it is not possible to prevent digests (MDF, SHA1, SHA256, and
whatever) from being copied to other sites and also forged there, the
only serious end-to-end protection between us as the producers of
consumer-software downloads and the individual who installs the
software is to also incorporate digital signatures into the downloads
themselves. Then facilities of the platform operating system could
be relied upon to provide confirmation of the authenticity and
integrity of the binary download. This practice is well-established
for Windows and our largest group of consumer-software users. I
don't know what the arrangements are with respect to other platforms
when the binary is downloaded directly by the user rather than
provided as a platform update.
OK, much of what you're describing/explaining here is out of my purview
I think. I will take a look at the scripting Joe pointed us to, and see
what I can get from that. I can't make any huge promises at the moment,
but I will report what I find.
(External signatures don't work for consumer software, although that
might be fine for our source-release tar balls. It is probably wise
to handle the external signatures the same way as the hash-function
digests, if not already handled in a secure way.)
[With a hat tip to Dan Boneh who covered Message Authentication Codes
and the use of digest algorithms with them in Week 3 of Stanford
University's on-line Cryptography
course,<https://www.coursera.org/#course/crypto>.]
- Dennis
-----Original Message----- From: Kay Schenk
[mailto:kay.sch...@gmail.com] Sent: Saturday, April 14, 2012 09:21
To: ooo-dev@incubator.apache.org Subject: Re: [DL LOGIC] How to
choose a mirror when more than 1 is available?
On 04/07/2012 09:45 PM, Dennis E. Hamilton wrote:
I agree that it is far more appealing to do this server side
rather than have the client user agent have to fire up only to do
a redirect.
It also leaves open the prospect of handling the failure modes
more effectively.
Of course, that change can be done at any time, perhaps when there
is no peak load on the horizon?
- Dennis
I'll take a look at this when I get a moment this weekend. I
understand Dennis's concern about the scarey aspects of changing
mirror sites in the JS we currently use especially given the number
of committers we have now with access to the entire web tree.
I'm assuming if we did use server-side mirror selection logic, we
would just specify the Apache mirror for ooo ---
http://apache.tradebit.com/pub/incubator/ooo/ -- and let server side
logic figure it out from there.
-----Original Message----- From: Dave Fisher
[mailto:dave2w...@comcast.net] Sent: Saturday, April 07, 2012
20:02 To: ooo-dev@incubator.apache.org Subject: Re: [DL LOGIC] How
to choose a mirror when more than 1 is available?
Hi Joe,
While everyone else might be ignoring the distinction between the
Apache closer cgi/ezt and the current OOo javascript methods, I
haven't missed the difference. One is server and the other client.
[ ... ] -- Robert Heinlein
--
------------------------------------------------------------------------
MzK
"Women and cats will do as they please,
and men and dogs should relax and get used to the idea."
-- Robert Heinlein
