Kay, thanks for noticing the security issue around having a script served from an insecure web page.
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). 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.) 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. (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
