Skip to main content
D
dews
Inspiring
November 11, 2015
Answered

Secure Socket Policy File issues

  • November 11, 2015
  • 1 reply
  • 3788 views

Ok, this is a bit of an odd one.  Little background: The site is internal - so rather than a second IP to handle socket connections, we're using port 8088.  We are also making both a secure and non-secure connection.

I wrote two simple java socket servers to respond to policy file requests - one insecure on 843 and one secure on 844.  Both appear to be working as expected.  My logs show the request comes in on :843 and the policy file is sent.  Logs also show the request comes in on :844 and the policy file is sent.

If I don't serve a policy on 843 then the policy file on 844 is never read.

In order for the secure policy to be read - I added this in one the class files:

Security.loadPolicyFile("tlssocket://mydomain.com:844");



The policy file is the same for both.

<?xml version="1.0"?>

<!DOCTYPE cross-domain-policy SYSTEM "/xml/dtds/cross-domain-policy.dtd">

<cross-domain-policy>

   <site-control permitted-cross-domain-policies="master-only"/>

   <allow-access-from domain="*" to-ports="*" />

</cross-domain-policy>

The error that's being thrown suggests that sure enough the policy file is being read - however, it's complaining about the <site-control> tag and stops??

*** Security Sandbox Violation ***

Connection to mydomain.com:8088 halted - not permitted from https://mydomain.com/includes/myswf.swf?nocache=111115102420

Warning: Ignoring <site-control> tag in policy file from tlssocket://mydomain.com:844.  This tag is only allowed in master policy files.

Has anyone run into issues like this serving secure policy files?

This topic has been closed for replies.
Correct answer jeromiec83223024

Yeah, that socket server article is not very helpful.  In practice, many socket servers are custom or proprietary, so there's no really useful how-to guide to write on that front.

Secure socket support gets a little more complex, as some browsers (Chrome) have more complicated handshakes than others for TLS, so your socket server needs to be able to negotiate multiple handshake styles, but that's not a Flash issue per-se.

In terms of the socket policies themselves, this is the best reference:

Policy file changes in Flash Player 9 and Flash Player 10 | Adobe Developer Connection

This whitepaper offers a more in-depth guide on policy files in general:

White paper: Adobe Flash Player 10 security | Adobe Developer Connection

In short, the master socket policy file must be served from 843.  This requirement exists, effectively to prove that you administer the domain.  All it has to do is serve that response, so you don't necessarily need something complex to do that work. 


The reasoning here (and this was all driven by research and real-world abuse), is that if any arbitrary port could set policies for all ports on the domain, that's highly problematic, if for instance, an attacker could exploit a weakness in one socket server that could then be used to escalate privileges to other socket-based services running on different ports on the same domain. 


From the master policy, you can set the ability of other ports to serve their own port-specific policies (although in practice, I can't think of a good reason off the top of my head), but you *have* to serve up the master first.

So, if you wanted to allow Flash to access port 844 on your domain, you would probably want to do something like this on port 843:

<cross-domain-policy>

     <site-control permitted-cross-domain-policies="master-only">

     <allow-access-from domain="mysite.com" to-ports="844">

</cross-domain-policy>

At that point, if you need 844 to also serve a policy file to further tune behavior for that port, and you've allowed it in the master socket policy file served on 843, then we'll go on to request a second policy file from 844 and parse those directives as well.

Also, if you wanted to enforce that the SWF requesting access to port 844 had to be served to the client via HTTPS, then you would do this:

<cross-domain-policy>

     <site-control permitted-cross-domain-policies="master-only">

     <allow-access-from domain="mysite.com" to-ports="844" secure=true>

</cross-domain-policy>

That doesn't magically enable TLS on the socket, but it does ensure that the client SWF was served securely to the client.  (i.e., there's no sense in encrypting the socket, if you can MITM the code interacting with the socket in the first place).


If you want to establish the socket connection over TLS, then you need to make the socket request using the SecureSocket class, at which point I think it still requests the policy of 843, but will fail if it can't complete a TLS handshake as part of that request (so both 843 and the target port would need to be able to handle TLS negotiation for that domain).

Hope that helps clarify things. 

1 reply

D
dewsAuthor
Inspiring
November 13, 2015

I believe I've exhausted the search on this topic - what I have found are just more questions.

Can Adobe please jump in with some advice on serving Socket Policy files when using SecureSocket's?

Or is there a link I've missed that addresses this topic that someone can share?

Ideally if the following KB from 2008 can be updated by Adobe with a working example, it will help the sure-to-be-growing-number-of-developers who'll be taking advantage of SecureSocket support for iOS as of Air 20: Setting up a socket policy file server | Adobe Developer Connection

Thanks much,

jeromiec83223024
jeromiec83223024Correct answer
Inspiring
November 17, 2015

Yeah, that socket server article is not very helpful.  In practice, many socket servers are custom or proprietary, so there's no really useful how-to guide to write on that front.

Secure socket support gets a little more complex, as some browsers (Chrome) have more complicated handshakes than others for TLS, so your socket server needs to be able to negotiate multiple handshake styles, but that's not a Flash issue per-se.

In terms of the socket policies themselves, this is the best reference:

Policy file changes in Flash Player 9 and Flash Player 10 | Adobe Developer Connection

This whitepaper offers a more in-depth guide on policy files in general:

White paper: Adobe Flash Player 10 security | Adobe Developer Connection

In short, the master socket policy file must be served from 843.  This requirement exists, effectively to prove that you administer the domain.  All it has to do is serve that response, so you don't necessarily need something complex to do that work. 


The reasoning here (and this was all driven by research and real-world abuse), is that if any arbitrary port could set policies for all ports on the domain, that's highly problematic, if for instance, an attacker could exploit a weakness in one socket server that could then be used to escalate privileges to other socket-based services running on different ports on the same domain. 


From the master policy, you can set the ability of other ports to serve their own port-specific policies (although in practice, I can't think of a good reason off the top of my head), but you *have* to serve up the master first.

So, if you wanted to allow Flash to access port 844 on your domain, you would probably want to do something like this on port 843:

<cross-domain-policy>

     <site-control permitted-cross-domain-policies="master-only">

     <allow-access-from domain="mysite.com" to-ports="844">

</cross-domain-policy>

At that point, if you need 844 to also serve a policy file to further tune behavior for that port, and you've allowed it in the master socket policy file served on 843, then we'll go on to request a second policy file from 844 and parse those directives as well.

Also, if you wanted to enforce that the SWF requesting access to port 844 had to be served to the client via HTTPS, then you would do this:

<cross-domain-policy>

     <site-control permitted-cross-domain-policies="master-only">

     <allow-access-from domain="mysite.com" to-ports="844" secure=true>

</cross-domain-policy>

That doesn't magically enable TLS on the socket, but it does ensure that the client SWF was served securely to the client.  (i.e., there's no sense in encrypting the socket, if you can MITM the code interacting with the socket in the first place).


If you want to establish the socket connection over TLS, then you need to make the socket request using the SecureSocket class, at which point I think it still requests the policy of 843, but will fail if it can't complete a TLS handshake as part of that request (so both 843 and the target port would need to be able to handle TLS negotiation for that domain).

Hope that helps clarify things. 

    D
    dewsAuthor
    Inspiring
    November 21, 2015

    This is a great help, thank you for taking the time to respond, much appreciated!

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices