incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: [DL LOGIC] How to choose a mirror when more than 1 is available?
Date Sat, 14 Apr 2012 19:01:32 GMT
On Sat, Apr 14, 2012 at 1:59 PM, Dennis E. Hamilton
<dennis.hamilton@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.schenk@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:dave2wave@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
>

Mime
View raw message