Adobe’s new Flash socket policy rules

May 7, 2008

With the release of Flash Player 9,0,124, Adobe has decided to change the way that socket policy files are handled. They have put together a 7 page article that gives an overview of the issue, but does not really provide enough specific information to let you solve the problem.

The product on which I am currently working uses a socket server on the back end. The client is in constant communication with this server (we also use a crossdomain.xml to allow us to access web services, but that stuff hasn’t changed).

Prior to the latest Flash player, we could simply serve a crossdomain.xml via a web server on port 80 and that would allow the client to connect on the socket that we specified. As of the upgrade, this no longer works.

After reading through the limited info that we could find about this upgrade, we finally figured out what our problem was; in order for a socket policy file to work, it must be served via a socket server (as opposed to an HTTP server). If a policy file is served via HTTP, it only works to allow HTTP requests (like HTTPService).

There was repeated mention of a policy socket server in the Adobe article, but there were no concrete examples. So one of our backend types (thanks Dave) whipped one up. It works like a charm. Basically, this server spews out the XML content of a socket policy file (think crossdomain.xml) whenever a client connects to it.

I’m using Security.loadPolicyFile('xmlsocket://' + serverName + ':' + socketPolicyPort); to load the policy info in my client. This is required because we are not using the Adobe “standard” of serving these policies on port 843 which would allow the client to automatically load the policy without explicit code in the client.

The contents of the policy data served looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<cross-domain-policy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://www.adobe.com/xml/schemas/PolicyFileSocket.xsd">
<allow-access-from domain="[redacted]" to-ports="[redacted]" secure="false"/>
</cross-domain-policy>

The allow-access-from line is where you make your money. The from attribute specifies that this line applies to swfs served from these locations (*.yourdomain.com for example). The to-ports attribute lists the port(s) on this server that you will allow access to. You can specify “7400”, “7500, 7502” or “7600-7610”. You can even get crazy and specify “7700, 7702, 7800-7820”. I’m pretty sure the secure attribute is only used for HTTP policy files, but we still have it there because it makes us happy (and because we totally cut and pasted this from our old HTTP crossdomain.xml).

Hope this helps.

Advertisements

11 Responses to “Adobe’s new Flash socket policy rules”

  1. Ryan Stewart Says:

    Hey Paul, thanks a lot for posting this. Very good explanation.

    =Ryan
    rstewart@adobe.com

  2. Henk Says:

    I just spend two days of reading and attempting to fix the application that suddenly broke. You guessed it, the socket policy file problem.

    I’l like to ‘comment’ about Adobe’s decision to only serve socket
    policy files through port 843.

    Forcing the use of port 843 requires the ISP to open up port 843 and run a
    new server. Every developer that develops an application using raw sockets
    now has to provide a hardened server for port 843 or somehow convince the
    ISP to install this server and run it. Good luck with that. My ISP will
    happily let me upload flash code to my site, but they will laugh at me if
    I ask them to run a server and oh open the firewall too.

    Why not allows a socket policy file to be served through a hardened server
    like Apache? Actually they do allow it, the file is read and the policy
    log reports a nice OK on it. The policy is not applied though, unless it
    is read through socket 843.

    Lets look at a simple use case. Lets develop a nice IMAP frontend and
    install it on the host that also runs the IMAP server. Well, that will no
    longer work. The Flash Application is not allowed to connecting to port
    993 (IMAPS) on the same server, even with a policy file served through
    HTTPS. Funny enough, if you run the same flash code on your local PC and
    let it connect to a remote socket then things work just fine.

    Adobe should be commended for their efforts in providing a secure solution.
    In this case it wasn’t very well thought out. The irony of it all is that
    in their attempt to improve security, Adobe frustrates their customers and
    forces them to make their servers less secure.

    Bottom line is that it is good to provide security measures, but not good
    not to allow us, developers, to manage them in the way they see fit.

    Cheers,
    Henk

  3. Paul Says:

    Henk, I feel your pain, and maybe I’m not understanding your issue correctly, but from what we experienced, it wasn’t that we weren’t serving the policy on port 843 (on our soon-to-be production servers, we’re serving the policy on a different port), it is that you can’t serve a policy via HTTP and have it apply to sockets. From what we discovered, you must either serve the policy on 843 or use Security.loadPolicyFile(‘xmlsocket://’ + serverName + ‘:’ + socketPolicyPort). The magic is in the protocol.

    Doesn’t solve your ISP issue, but it does make a difference.

  4. Henk Says:

    Hello Paul, thanks for the reply.
    Yes agreed, it does make a difference. You’re giving me an idea. If the webserver runs on 443 (HTTPS) then the policy file can be served on port 80. That would work around the firewall issue for me.
    The server can be extremely simple as demonstrated here: http://www.lightsphere.com/dev/articles/socketpolicy.pl.html.
    It still doesn’t fully solve the ISP issue. What is the problem with allowing the policy file to be served through HTTP?

  5. Ben Says:

    THANK YOU SO MUCH! I’ve been fighting this for days, and thanks to you I have a few hairs left on the top of my head that I didn’t pull out!


  6. […] With the release of Flash player 9 Update 3, many Flash applications are beginning to break due to Flash’s new socket policy rules. […]

  7. Sean Says:

    I wish adobe did a better job in providing more ( clearer ) docs.

    Sean.

    Free AIR Powered Digital Signage
    http://www.MediaSignage.com

  8. Stefan Says:

    Had quite a time getting this to work.
    One tip that I can offer:

    When Flash establishes a connection to the selected port and it requests the policy file, write the XML back through the socket and CLOSE THE CONNECTION. The socket object in flash will then create a new connection and behave as normal.

    I kept the connection open, expecting that the socket is now connected. By doing that, the security check timed out leaving me with the same error as before.

  9. Paul Says:

    Stefan,

    Thanks for the extra info.

  10. Tom Says:

    Adobe doesn’t adequately define the “null” (no policy specified) situation – what happens when you don’t have a policy on whichever interface they happen to be checking. Does it assume a “deny” or a “check-next-level”? imo they totally ballsed this one up – they got it backwards – they should be checking for a policy on the target port itself FIRST, then if a “null” occurs, fall back to global policies etc.

    I run a web app with over 100 million hits a day, and that TCP connection to 849 followed by the target-port connection and policy serving on that port just-in-case, amounts to enormous waste. Flash = Bloatware. Security on the internet should be reactive: pre-empting incurs an enormous hidden cost. A few phishing incidents are not.

  11. Tom Says:

    Adobe doesn’t adequately define the “null” (no policy specified) situation – what happens when you don’t have a policy on whichever interface they happen to be checking. Does it assume a “deny” or a “check-next-level”? imo they totally ballsed this one up – they got it backwards – they should be checking for a policy on the target port itself FIRST, then if a “null” occurs, fall back to global policies etc.

    I run a web app with over 100 million hits a day, and that TCP connection to 849 followed by the target-port connection and policy serving on that port just-in-case, amounts to enormous waste. Flash = Bloatware. Security on the internet should be reactive: pre-empting incurs an enormous hidden cost. A few phishing incidents do not.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: