incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: [DL LOGIC] How to choose a mirror when more than 1 is available?
Date Sat, 14 Apr 2012 18:57:13 GMT
Notice that the same security concerns around authenticity and integrity of downloads applies
to extension and template downloads as well.

There is currently no embedded signature mechanism for .oxt files, although there could be
if .oxt were upgraded to use genuine ODF packages and ODF 1.2 digital signatures.  (The current
.oxt is a Zip package using a custom, pre-ODF profile.)  This would also work for third-party
contributors (and be much less expensive than requiring code-signing certificates), be platform-independent,
and be extensible to bundling of any other Apache OpenOffice artifacts for which authentication
is important.

 - Dennis

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
Sent: Saturday, April 14, 2012 10:59
To: ooo-dev@incubator.apache.org
Subject: RE: [DL LOGIC] How to choose a mirror when more than 1 is available?

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