So, you're saying that serving the .SWF via HTTPS won't automatically make all my ColdFusion calls through HTTPS? Like, I can have the majority of my calls through HTTP, and just secure the couple of calls that need to be secured?
I thought if you served the .SWF via HTTPS, all the calls to CF were automatically sent through HTTPS? L. --- In [email protected], "valdhor" <valdhorli...@...> wrote: > > 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" <LMacNeill@> 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. > > > > > > > > > >
