Computers as Theatre it is, Alex.
I'm liking a lot what I read and start to understand what you've been
hinting at in other posts. Looking forward to look into your code and
understand your ideas in more detail.
Rui
To fill in some gaps.
An MD5 or SHA256 hash does not provide real security and it can't prevent Man
in the middle attack. Here is why:
To validate a HASH you must have a "valid" HASH value to compare against. The
issue is... if you don't trust the RSL, how do you trust the HASH value you are
On 2/21/12 2:33 AM, "David Arno" wrote:
> Is this on your whiteboard yet so that we can all take a look? If not, I
> look forward to you putting it there soon as I'd be interested in how you
> achieved this.
I don't even have a whiteboard folder yet. And it looks like these
prototypes needs
On 21 February 2012 11:33, David Arno wrote:
> > From: Alex Harui [mailto:aha...@adobe.com]
> > Sent: 20 February 2012 19:18
> >
> > I have a prototype of a framework that leverage the zero-install
> capability of Flash
> > much better, which should eliminate the need for RSLs.
>
> Is this on you
> From: Alex Harui [mailto:aha...@adobe.com]
> Sent: 20 February 2012 19:18
>
> I have a prototype of a framework that leverage the zero-install
capability of Flash
> much better, which should eliminate the need for RSLs.
Is this on your whiteboard yet so that we can all take a look? If not, I
> From: Haykel BEN JEMIA [mailto:hayke...@gmail.com]
> Sent: 20 February 2012 16:00
> Talking about security, I think there is nothing being done to
> prevent man-in-the-middle for JS libraries hosted by Google
> for example, so it does not seem to be an issue even if JS is plain
> text and eas
Hi,
>> Also you can you can compile any other changes you
>> require right into the Flex framework. This makes RSLs actually usable again.
> I'm not sure I understood this.
We can compile our own framework RSLs by applying any unsubmitted monkey
patches directly to a local copy of the source cod
On 2/20/12 3:51 PM, "arielj...@yahoo.com" wrote:
> Can we program the loader to pull the hash from a URL via ssl?
There are lots of possibilities. Basically, if you are fetching the answer
to a question, you allow both the question and answer to be hacked to get
any answer you want. It will
On 2/20/12 1:02 PM, "Justin Mclean" wrote:
> Hi,
>
>> Also note that many large apps seem to have given up on RSLs because they've
>> had to hack the classes in the RSLs to fix bugs.
> Once the the project is up and running fully (people submitting patches etc
> etc) this will be less of an i
On 2/20/12 11:40 AM, "Michael A. Labriola"
wrote:
>
> I always thought it would be interesting to stream the first two frames from a
> server. Then keep alive the connection, use some connection to a server to
> indicate which classes were needed next and just stream additional frames each
>
Can we program the loader to pull the hash from a URL via ssl?
Ariel Jakobovits
ajako...@adobe.com
650-350-0282
On Feb 20, 2012, at 1:02 PM, Justin Mclean wrote:
> Hi,
>
>> Also note that many large apps seem to have given up on RSLs because they've
>> had to hack the classes in the RSLs to fi
Hi,
> Also note that many large apps seem to have given up on RSLs because they've
> had to hack the classes in the RSLs to fix bugs.
Once the the project is up and running fully (people submitting patches etc
etc) this will be less of an issue as there will be less need to monkey patch
any Flex
On 21/02/2012 04:36, Haykel BEN JEMIA wrote:
loader.swf will also be loaded with the app and can be hacked by a m-i-t-m
attack.
The purpose of the loader is that a application that is loaded uses
verified libraries. If the initial
access to the embedded loader.swf is corrupted by a m-i-t-m then
>wouldn't that be essentially the same as them "blessing" our framework, which
>is something they were unwilling to do in the first place? From what I
>remember, that is the entire beef they had -- they didn't want to say that our
>>framework was worthy of an RSL, unless it went through their s
wouldn't that be essentially the same as them "blessing" our framework,
which is something they were unwilling to do in the first place? From what
I remember, that is the entire beef they had -- they didn't want to say
that our framework was worthy of an RSL, unless it went through their
security
>Flex does not leverage that aspect of Flash. Like Java, it has code
>libraries which can be substantial in size. Unlike Java, it does not
>supported class loading on the fly. You have to preload the code before
>making access to a class.
Alex,
I always had a theory I wanted to try out but n
loader.swf will also be loaded with the app and can be hacked by a m-i-t-m
attack.
Sorry for the short message. Sent from my tablet.
Le 20 févr. 2012 20:29, "Martin Heidegger" a écrit :
> On 21/02/2012 04:18, Alex Harui wrote:
>
>> I don't think we can find a way to know that a file downloaded f
On 21/02/2012 04:18, Alex Harui wrote:
I don't think we can find a way to know that a file downloaded from one mirror
is
the same as one coming from another mirror without downloading it in the
first place.
What is wrong about an approach where the "loader.swf" has MD5 hash of
the files? It
has
On 2/20/12 9:26 AM, "Bertrand Delacretaz" wrote:
> Hi Omar,
>
> On Mon, Feb 20, 2012 at 8:56 AM, Omar Gonzalez
> wrote:
>
> In the case of RSLs I assume signatures are checked by the client,
> what are the requirements for that?
RSL signatures are checked by the Flash Player.
Flash is a ze
Hi Omar,
On Mon, Feb 20, 2012 at 8:56 AM, Omar Gonzalez
wrote:
> ...RSL stands for runtime shared library. Portions of the Flex SDK are
> compiled into .SWZ files that are(were) signed by Adobe. This would yield
> two benefits, 1.) security and 2.) Flash Player RSL caching at a global
> level (al
On 20 Feb 2012, at 16:56, Omar Gonzalez wrote:
> 1.) security and 2.) Flash Player RSL caching at a global
> level (all domains),
> Having Apache host RSLs would help us to
> resolve #1 as Adobe will no longer host our RSLs. I hope that's clear and
> that I've gotten that all correct, someone co
On Mon, Feb 20, 2012 at 8:50 AM, Bertrand Delacretaz wrote:
> Hi,
>
> On Mon, Feb 20, 2012 at 1:03 AM, jude wrote:
> > ..In the whitepaper there was mention that Adobe would not be signing the
> > framework RSL compiled by the Apache Flex project. That's a big hit for
> > downloading every time.
Hi,
On Mon, Feb 20, 2012 at 1:03 AM, jude wrote:
> ..In the whitepaper there was mention that Adobe would not be signing the
> framework RSL compiled by the Apache Flex project. That's a big hit for
> downloading every time. Is there a way to get the Apache Flex RSL signed?...
I have no idea wha
Talking about security, I think there is nothing being done to prevent
man-in-the-middle for JS libraries hosted by Google for example, so it does
not seem to be an issue even if JS is plain text and easier to manipulate
(I did not hear about such an attack). Is the RSL issue we are talking
about a
On 20 Feb 2012, at 15:30, Haykel BEN JEMIA wrote:
>> Although: I suspect with effort, it is possible for suitably skilled for
>> man-in-the-middle attacker to intercept the loader SWF and replace the
>> byte-code storing the MD5 values their own and still inject badLibrary.
> What about storing t
Haykel Ben Jemia
Allmas
Web & Mobile Development
http://www.allmas-tn.com
On 20 February 2012 14:52, Paul Evans wrote:
>
> Although: I suspect with effort, it is possible for suitably skilled for
> man-in-the-middle attacker to intercept the loader SWF and replace the
> byte-code storing the
> From: Paul Evans [mailto:paulev...@creative-cognition.co.uk]
> Sent: 20 February 2012 13:53
>
> Sorry - still thinking up problems rather than solutions.
I think that is the best way with anything to do with security.
David.
On 20 Feb 2012, at 13:19, David Arno wrote:
>> * can i get a badLoader into the application
> Probably. After all, what happens if someone spoofs the apache flex download
> site and provides a dodgy version of the SDK? But that's a whole different
> issue.
Yeah, though signed RSLs currently prot
David,
you just brought up a question in my mind: What if we don't use the
"global index" at runtime but also at compile time:
programmer
-> Defines "RSL" with compile-time swc/f and online path and
eventual failbacks
compiler
-> Creates MD5 from from swc/f
-> Compares
On Feb 20, 2012 1:21 PM, "Michael A. Labriola"
wrote:
> I am not going to hold my breath on this, but the way to avoid this would
be to have adobe host a minimal-sized, signed rsl, that contained our
hashes. Then we have the hashes with a level of confidence.
Can't the hashes of all used librarie
>more specifically... If attacker succeeds in the above, every app that wants
>to use the same library version is compromised by that browser cache even
>after leaving the 'man-in-the-middle' compromised network.
I am not going to hold my breath on this, but the way to avoid this would be to
h
> From: Paul Evans [mailto:paulev...@creative-cognition.co.uk]
> Sent: 20 February 2012 12:41
> i don't know enough about security, but in probing for flaws in that idea
I'd approach from:
I don't know much about security either. Thus why I'm questioning whether it
can be done, rather than just s
On 20 Feb 2012, at 12:41, Paul Evans wrote:
> * Can I 'man-in-the-middle' and inject badLibrary with corresponding md5 to
> make it look good - i.e. spoof the central repository
> * can i get a badLoader into the application
more specifically... If attacker succeeds in the above, every app that
On 20 Feb 2012, at 11:50, David Arno wrote:
> If we generate MD5 hashes for the SDK SWCs,
> then the loader could check those hashes on load. Would that not be secure
> enough, or is there a flaw in that idea?
i don't know enough about security, but in probing for flaws in that idea I'd
approac
Hi,
> Not sure if I'm getting confused here, but I thought we couldn't use RSLs as
> Adobe won't sign them?
We can still use RSLs both framework RSLs and user compiled/non framework RSLs.
Apache framework RSLs will not be cached by the flash player but they can be
cached by the browser (on a dom
On 20 Feb 2012, at 11:07, Martin Heidegger wrote:
> The Flashplayer does cache swfs if they come from the same domain.
No, the browser caches SWFs, not flash player.
On 20 Feb 2012, at 12:04, Martin Heidegger wrote:
> The flash player caches the signed RSL's differently.
Yes, but flash player
> From: Martin Heidegger [mailto:m...@leichtgewicht.at]
> Sent: 20 February 2012 12:04
>
> The flash player caches the signed RSL's differently. [1]
Not sure if I'm getting confused here, but I thought we couldn't use RSLs as
Adobe won't sign them? So Apache Flex will need to be based on plain,
un
> The flash player caches the signed RSL's differently. [1]
>
> [1] http://livedocs.adobe.com/flex/3/html/help.html?content=rsl_09.html
>
> yours
> Martin.
A more up-to-date version
http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf69084-7add.html
--
Mansour Blanco
Software e
On 20/02/2012 20:50, David Arno wrote:
From: Paul Evans [mailto:paulev...@creative-cognition.co.uk]
Sent: 20 February 2012 10:20
From previous discussion, Alex raised concern of potential exposure to a
man-in-the-middle attack - unless we find a way of getting them signed.
Do they really need
> From: Paul Evans [mailto:paulev...@creative-cognition.co.uk]
> Sent: 20 February 2012 10:20
>
> From previous discussion, Alex raised concern of potential exposure to a
> man-in-the-middle attack - unless we find a way of getting them signed.
Do they really need signing? If we generate MD5 has
The Flashplayer does cache swfs if they come from the same domain.
Apache could offer a central library repository that would be much like
Google JavaScript repository. Its not a RLS but could be equally worth
it. However Google's infrastructure (connections, routing, etc.) is
awesome, no idea
Thanks for the link Paul. Indead this is a big issue and I think it can not
be fixed as only Adobe can create signed RSLs! Let's make them as small as
possible for now.
Haykel
On 20 February 2012 11:20, Paul Evans wrote:
>
> On 20 Feb 2012, at 09:54, David Arno wrote:
>
> > The idea that Hayk
On 20 Feb 2012, at 09:54, David Arno wrote:
> The idea that Haykel was suggesting though would be to avoid serving it from
> individual hosts and to serve it globally instead. That way the browser only
> has to cache it once, not once per domain. There would be cross-domain
> issues, but I thi
> From: Jarosław Szczepankiewicz [mailto:jszczepankiew...@gmail.com]
> Sent: 20 February 2012 09:44
>
> caching the RSL in the browser is already used and ready (as far as
> www server is properly using Etag etc. headers). Apache http is
> caching static resources very well out of the box (at le
caching the RSL in the browser is already used and ready (as far as
www server is properly using Etag etc. headers). Apache http is
caching static resources very well out of the box (at least if it is
not in clusters which may broke Etag). The most important result of
the adobe announcement is that
2012/2/20 David Arno :
>> From: Haykel BEN JEMIA [mailto:hayke...@gmail.com]
>> Sent: 20 February 2012 09:27
>>
>> Is it possible to enhance the preloader to download required RSLs from
>> a central Apache repository or are there any technical or FP security issues
>> that would make this impossibl
> From: Haykel BEN JEMIA [mailto:hayke...@gmail.com]
> Sent: 20 February 2012 09:27
>
> Is it possible to enhance the preloader to download required RSLs from
> a central Apache repository or are there any technical or FP security issues
> that would make this impossible?
Unless it is technica
Is it possible to enhance the preloader to download required RSLs from a
central Apache repository or are there any technical or FP security issues
that would make this impossible?
Haykel
On 20 February 2012 10:17, Roland Zwaga wrote:
> >
> > In the whitepaper there was mention that Adobe wou
>
> In the whitepaper there was mention that Adobe would not be signing the
> framework RSL compiled by the Apache Flex project. That's a big hit for
> downloading every time. Is there a way to get the Apache Flex RSL signed?
>
I believe this is impossible, the Flash Player will only cache RSL's t
49 matches
Mail list logo
