flash socket policies update

I’ve been getting a lot of positive feedback recently on the post I made last December on this topic, so it’s probably time to post an update.

Last week, Adobe finally released some help for people who need to provide socket policy services. They’ve got python and perl versions of the socket policy daemon that look like they can run either standalone or through xinetd. They don’t claim that the code is production quality yet… but it’s at least something.

Of course, I released sample PHP code 5 months ago… shrug.

My confederates and I have spent the intervening months sniffing packets, yelling at flash, rewriting daemons, etc… until settling upon a version of the service that appears to function reliably now. I am currently running it on 6 different servers and have seen it successfully handle requests from >100 simultaneous users during stress tests.

The biggest problem with my previous versions of the code was how I handled closing of connections. Previously, I had simply accepted connections and fired off the policy xml without waiting for a request from the client.

This worked 95% of the time over a good net connection, and more like 80% of the time over a poor connection.

The reason it didn’t work consistently was because of weird tcp ordering issues. Connections would be closed out of order, the response would be received before the request was dispatched, etc..

My new version is much more robust and actually waits for flash to submit the request before sending the XML. I consider it release candidate beta quality code and hope to be able to release it later today.

update

Version 0.9.b is available now.

One thought on “flash socket policies update”

  1. I’d like to give some feedback on the socket policy file article
    http://www.lightsphere.com/dev/articles/flash_socket_policy.html

    First, its a great article. It sums up about a dozen pages of Adobe
    documentation that mostly results in confusing people.

    Second, 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

Leave a Reply

Your email address will not be published. Required fields are marked *