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
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:
This whitepaper offers a more in-depth guide on policy files in general:
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:
<allow-access-from domain="mysite.com" to-ports="844">
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:
<allow-access-from domain="mysite.com" to-ports="844" secure=true>
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.
This is a great help, thank you for taking the time to respond, much appreciated!