Ok, then... Fantastic. I am using AMF to communicate with the CFC's, and I'm using the SecureColdFusion channel I created to transfer the secure stuff, and the regular ColdFusion channel to transfer the non-secure stuff... So even if I serve the .SWF over HTTPS, nothing will change (except I won't need to set 'secure="false"' in my crossdomain.xml file.) Perfect.
So far, the only major differences I've noticed between CF8 and CF9 are the configurations of the channels themselves. I found a comparison in this article: http://help.adobe.com/en_US/ColdFusion/9.0/Developing/WS5B9C73A8-5FA2-4a54-B0C6-CECA2E20052D.html That, and the fact that my un-patched CF 8.01 server didn't enforce the "public" vs. "remote" policies on the functions in my .CFC's. I've checked all my CFC functions to ensure that they have 'access="remote"' set in the <cffunction> declaration. Other than that, I've made no changes to my .CFCs, and they work fine with CF9. But I've only been running CF9 for about a week or so? I'm sure I'll notice other differences as time goes on. But, so far, the transition to CF9 really hasn't been all THAT bad. Just gotta make sure you specify CF9 when you're asking for advice -- that was my earlier mistake, assuming CF8 and CF9 were more similar than they actually are. Best of luck in your transition. Hope my experience helps you to avoid a couple of the pitfalls I fell into. :-) L. --- In [email protected], "Warren" <warrenony...@...> wrote: > > It depends on how you are communicating with the CFC. > > If you are using the remoting protocols, then how those channels are > configured is what counts. Just because the swf is served thru HTTPS doesn't > mean your data will be IF you are using the AMF channels. I have used (in > test) https channels under an http web server. If you want secure data > transmission under AMF then you need to create and use a secure channel. > > If you are using other means (wsdl, URL, parameters, etc.) to move data back > and forth, then the web server protocol comes into play. > > It would be nice for someone from Adobe to comment on this, especially with > some sort of overview of the differences between CF8 and CF9. I'm going to > have to move soon to CF9 and you've already found one difference in the > services-conf.xml file (the endpoints) that I'm going to have to deal with. > > ----- Original Message ----- > From: Laurence > To: [email protected] > Sent: Monday, February 22, 2010 3:16 PM > Subject: [flexcoders] Re: Security issues SOLVED. (Mostly...) > > > > 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" <valdhorlists@> 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. > > > > > > > > > > > > > > >
