An Idea... Put the SWF on the HTTPS Server. There will be a one time hit as the user loads the SWF. Place your secure calls to the same HTTPS server. Place the other calls to an HTTP server.
I don't know how or even if that would work but it's worth a try. --- In [email protected], "Laurence" <lmacne...@...> wrote: > > Yes but HTTPS is *so* much slower than HTTP... Some of the data that we > don't need secured can get as high as 50,000 records... I only need one > credit-card number per account secured. Not much data at all... > > So how, exactly, does setting the secure="false" tag open it up to snooping > or spoofing? I still don't really get that... I mean, it's still using > HTTPS over the secure ColdFusion channel I created, right? Wouldn't that > still be secure? > > And if setting the secure="false" tag removes all HTTPS security, then why > bother offering the ability to create secure channels in ColdFusion? I mean, > if you're serving the .SWF over HTTPS, then all channels are automatically > secure, yes? So the only point of having a separate secure channel is to do > exactly what I'm trying to do... Why offer that, if it's not truly secure? > I'm still confused... > > L. > > > --- In [email protected], "valdhor" <valdhorlists@> wrote: > > > > > > > > > > From the Adobe Help files: > > ====================================================================== > > Each <allow-access-from> tag also has the optional secure attribute, which > > defaults to true. You can set the attribute to false if your policy file is > > on an HTTPS server, and you want to allow SWF files on a non-HTTPS server > > to load data from the HTTPS server. > > > > Setting the secure attribute to false could compromise the security offered > > by HTTPS. In particular, setting this attribute to false opens secure > > content to snooping and spoofing attacks. Adobe strongly recommends that > > you not set the secure attribute to false. > > > > If data to be loaded is on a HTTPS server, but the SWF file loading it is > > on an HTTP server, Adobe recommends that you move the loading SWF file to > > an HTTPS server so that you can keep all copies of your secure data under > > the protection of HTTPS. > > ====================================================================== > > > > If I needed secure access, I would move everything over to https. > > > > The only other thing I could suggest is to use encryption. Check out > > AS3Crypto (http://code.google.com/p/as3crypto/). Of course, if you serve > > the SWF over HTTP, someone could analyze the SWF and find the encryption > > key. Again, for security reasons, I would move everything over to https. > > > > --- In [email protected], "Laurence" <LMacNeill@> wrote: > > > > > > So, here's my crossdomain.xml in its final form: > > > > > > <cross-domain-policy> > > > <site-control permitted-cross-domain-policies="master-only" /> > > > > > > <allow-http-request-headers-from domain="www.mydomain.com" headers="*" > > > secure="false"/> > > > <allow-access-from domain="www.mydomain.com" secure="false" /> > > > > > > </cross-domain-policy> > > > > > > This allows all the stuff on the SecureColdFusion channel I created to > > > work just fine, as long as I access the site from "mydomain.com" and not > > > from "localhost" or "myserver01" (its NetBIOS name). > > > > > > Even if I put <allow-access-from domain="localhost"/> (or > > > domain="myserver01"/>) in there, it still won't allow access from > > > localhost (or myserver01), because the security certificate is issued to > > > mydomain.com -- the names don't match, so the browser/Flash/CF rejects > > > it. (I don't know exactly which one is rejecting it, but somewhere along > > > the line it's being rejected because of the name-mismatch.) > > > > > > The only way that I can see to change that behavior is to create two more > > > virtual websites that point to the same location, and give each of those > > > virtual sites their own certificate (one assigned to "myserver01" and one > > > assigned to "localhost". Otherwise, I can't access the app on my local > > > server if the Internet goes down. Yuck. (If anyone knows a better way, > > > I'm all ears.) > > > > > > The one thing that still bothers me about this setup is the > > > 'secure="false"' tags. I cannot get a straight answer as to exactly what > > > this does to my security. It enables http .SWFs to access https data, > > > sure. But does that mean it's disabling all https when it does that? Or > > > does it mean that it is secure during transit over the Internet, but not > > > when it's being held in the Flex app? Or does it mean something entirely > > > different? There is no site that has a direct answer to this -- they all > > > just say "it's not recommended due to security issues," or something > > > along those lines. But they don't specify WHAT security issues there > > > are. I need to know -- I can't serve my entire app over an https > > > connection because it'll be too slow, but I must have secure access to > > > some of the data... > > > > > > So if anyone can answer the 'secure="false"' question specifically, I > > > would be very grateful. > > > > > > Thanks, > > > L. > > > > > >
