On Sat, Apr 14, 2012 at 1:59 PM, Dennis E. Hamilton <dennis.hamil...@acm.org> wrote: > 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. >
That is already standard practice for Apache releases. Check any download page for an Apache release and you see the hashes are linked to the apache.org /dist directory. If you get that part right, everything else falls into place. At least for users who know enough to check hashes. Otherwise they are at risk from potentiality rogue mirror operators. Of course that has been true for over a decade with OOo, without any reported problems. So I'm not very concerned. I think we have enough real bugs to worry about. -Rob > 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 >
