incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <kay.sch...@gmail.com>
Subject Re: [DL LOGIC] How to choose a mirror when more than 1 is available?
Date Sat, 14 Apr 2012 22:28:54 GMT


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.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
>

-- 
------------------------------------------------------------------------
MzK

"Women and cats will do as they please,
  and men and dogs should relax and get used to the idea."
                                     -- Robert Heinlein

Mime
View raw message