Cross Domain FLASH

The Problem

Consider the following simple problem: Classic_Movie_Clips.com operates a service by which it provides streaming video of rare movies. Its business model is not consumer direct. Rather, it forms alliances with popular movie sites such as See_Movies_Here.com. When a user, Alice, logs onto See_Movies_Here.com and clicks on a link that is actually served by Classic_Movie_Clips.com, her browser makes a request to the latter site. How does Classic_Movie_Clips.com decide whether to grant Alice access?

Currently FLASH (either running within the browser, or in the AIR run time) will pull the crossdomains.xml file from Classic_Movie_Clips.com and see if See_Movies_Here.com is in that list. While this is fine for legitimate users, what if it is Connie the Content Thief who is "pretending" to be coming from See_Movies_Here.com?

Clearly some solution is needed, and they could range from forcing Classic_Movie_Clips.com to maintain an ID/password for Alice, or run a federation protocol, or do some one off cryptography.

These are all sub optimal options, and are band aids to the real problem, namely Classic_Movie_Clips.com needs a mechanism to be able to mutually authenticate with See_Movies_Here.com without having to trust the user in the middle. And the method better be efficient and not require expensive PKI operations for each instance of such a mash up.

The MashSSL Solution for Cross Domain FLASH

While there are many ways to integrate MashSSL the demo we built (see webcast below) takes one simple approach.

  • The user is logged into See_Movies_Here.com and the FLASH code she has downloaded has a cross domain request to Classic_Movie_Clips.com.
  • When Classic_Movie_Clips.com gets the request it redirects to See_Movies_Here.com with the first MashSSL Client_Hello message.
  • The rest of MashSSL then plays out between the sites using redirects, and at the end of which Classic_Movie_Clips.com knows it is dealing with See_Movies_Here.com, at which point it returns the request.

Notice the SSL PKI "heavy lifting" is only done the first time. If there are a million further similar mashups during that day, the very efficient abbreviated handshake which requires no public key operations, is used instead.