5

I have a Silverlight 5 application trying establish a socket connection to a server as follows:

var targetEndpoint = new DnsEndPoint("subdomain.maindomain.com", 443);
var clientSocket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
var socketAsyncEventArgs = new SocketAsyncEventArgs {RemoteEndPoint = targetEndpoint};
socketAsyncEventArgs.Completed += AsyncConnectCallback;
clientSocket.ConnectAsync(socketAsyncEventArgs);

I have the following clientaccesspolicy.xml file at https://subdomain.maindomain.com/clientaccesspolicy.xml :

<access-policy>
    <cross-domain-access>
        <policy>
            <allow-from http-request-headers="*" http-methods="*">
                <domain uri="https://subdomain.maindomain.com"/>
                <domain uri="*"/>
            </allow-from>
            <grant-to>
                <resource path="/" include-subpaths="true"/>
                <socket-resource port="4502" protocol="tcp"/>
            </grant-to>
        </policy>
    </cross-domain-access>
</access-policy>

I am able to run a local instance of the Silverlight application from visual studio and can establish the socket connection, both running in-browser as well as out-of-browser. When I deploy the application, I am still able to connect using the out-of-browser version, but the in-browser version errors out with the following message:

AccessDenied: An attempt was made to access a socket in a way forbidden by its access permissions.

Within my local environment, where I am running from Visual studio, if I create an hosts file entry:

127.0.0.1 myapp.local

and update my localhost in-browser instance (running from VS) to use myapp.local, I can reproduce the same error, which suggests that the error occurs when the root domain is not localhost, regardless of where the application is hosted.

I have checked my firewall and antivirus software's event logs for signs that they could be blocking the connection request, but do not see any evidence of that.

Has anyone else experienced this issue and offer suggestions of what my problem could be?

GPicazo
  • 6,516
  • 3
  • 21
  • 24
  • The port number in code and xml have a conflict. Port 443 is reserved(see https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers). Port number under 1000 are reserved and often blocked by firewalls and/or virus checker. The error for 127.0.0.1 maybe different than the port number. 127.0.0.1 is the loopback IP address and can only be used in Net library for listening (at server). Net Library will give an error if it is used in a Connect() method. – jdweng Dec 19 '16 at 18:02
  • The port numbers being different is not a conflict -- the port number in the xml is used for another purpose. I understand that 443 is reserved for TLS/SSL, but that is precisely why the socket connection is being established, to be able to forward TLS requests. – GPicazo Dec 19 '16 at 18:32
  • I did some integration of SSL years ago and don't remember all the details. You may want to reference the Wiki article : https://en.wikipedia.org/wiki/Transport_Layer_Security. I would use a sniffer like Wirsshark or Fiddler to find out exactly where in the protocol you are failing. The error messages from the Net Library are sometimes misleading. You also haven't specified what version of TLS you are using. Make sure it is correct version. – jdweng Dec 19 '16 at 20:00
  • I am using a 3rd party library (eldos secure blackbox) to handle the TLS details. I do use wireshark to monitor my TLS traffic, but in this case, the code does not make it far enough to start sending TLS requests. The socket that i am trying to open is the channel that would be used to send the TLS request packets, but I am not getting far enough to send the packets since the socket cannot be opened. In this case, the TLS implementation is irrelevant since establishing a normal socket connection is what is failing. – GPicazo Dec 19 '16 at 20:05
  • If no messages is being sent, then you are probably using 127.0.0.1 with the Connect() method. The Connect method must use the IP address (or name) of the Server. 127.0.0.1 is only used at the server to listen. The Net library will not send any messages from the client with 127.0.0.1 as the destination IP address. – jdweng Dec 19 '16 at 21:14
  • So you can't use myapp.local for the connect method since it is defined as 127.0.0.1. On some PCs Local localHost is defined as 127.0.0.1 and other PC localhost is defined as the computer name. This gets to be confusing and can create errors like what you are seeing. You may want to use the Environmental Variable COMPUTERNAME instead. To see the list of environmental variables open a cmd.exe window and type > SET. – jdweng Dec 19 '16 at 21:24
  • I am not using myapp.local for the connect method, I am using subdomain.maindomain.com. myapp.local is just an alias I created to prove that the connection issue occurs when running the in-browser client application from another domain besides localhost, as is the case when the application is deployed. Because the application instance is the same when run as localhost or myapp.local, but only works (connects) when run as localhost, then my idea is that some silverlight security restrictions are skipped when run as localhost only. I just don't know what those restrictions could be. – GPicazo Dec 19 '16 at 21:51
  • So what IP address do you get when from cmd.exe you issue > Ping localhost? I bet you don't get 127.0.0.1. I keep on saying NET LIBRARY WILL GIVE ERROR AN ERROR WHEN THE CONNECT METHOD USE 127.0.0.1. Simply change connection IP and you will see that I'm correct. This has nothing to do with silverlight security. – jdweng Dec 19 '16 at 22:40
  • A socket error can be caused by the antivirus or firewall software. Basically, a needed socket connection is being denied. Socket error is a message which implies that a port is blocked and/or unreachable. – huse.ckr Dec 22 '16 at 09:19
  • @user3060520 - I've checked firewall and antivirus already, but will check again since it's the most common issue I have read about for this problem. Also, if the port was being blocked, why would it work when run from localhost? – GPicazo Dec 22 '16 at 16:34
  • Is your silverlight control signed? – Yuriy Tseretyan Dec 27 '16 at 18:24
  • @YuriTceretian - Yes, it is – GPicazo Dec 27 '16 at 18:26
  • I think that a browser blocks network connection. Did you try to check property `Application.HasElevatedPermissions` when you get the exception? – Yuriy Tseretyan Dec 27 '16 at 18:29
  • I am not getting an exception, per se. The error message is returned in the SocketAsyncEventArgs parameter when the socket's ConnectAsync method completes it's connection attempts. Therefore, it is not raising an error during runtime that the end-user actually sees -- from a user's perspective, the application just hangs during the attempt to open the socket connection. – GPicazo Dec 27 '16 at 18:37
  • @GPicazo, I am almost sure that your problem is access restrictions. Check that article https://msdn.microsoft.com/en-us/library/ee721083(v=vs.95).aspx?f=255&mspperror=-2147217396#Anchor_0 – Yuriy Tseretyan Dec 27 '16 at 19:30
  • @YuriTceretian - I have looked into everything I can think of or read about relating to browser/silverlight restrictions. At this point, I think the issue might be the target server blocking the connection. – GPicazo Dec 27 '16 at 19:43
  • So, you are sure that in production in-browser mode your application has trusted permissions that allows you to open connection to a server that has domain different than your control's url to port 443 and clientaccesspolicy.xml is available through port 943? – Yuriy Tseretyan Dec 27 '16 at 19:47
  • The in-browser mode does have trusted permissions. The domain is actually the same once the application is deployed (but still doesn't work) -- it is only different when running the application locally. The clientaccesspolicy.xml is available on the correct port. The only part that I am not 100% sure, and will be looking into is that port 443 is not being blocked on the target server, either by a firewall or antivirus. – GPicazo Dec 27 '16 at 20:43
  • @YuriTceretian - While I have not been able to resolve the issue, I think you are correct that my problem is going to be access restrictions related, either due to SL restrictions or networking restrictions. I will update this post with my findings once I am able to find the solution. In the meantime, if you'd like to provide an official answer with the conversation we've had, I can mark it as accepted so you are awarded the bounty, which expires in less than a day. – GPicazo Dec 27 '16 at 23:13

2 Answers2

0

For Silverlight, you need a socket policy server in the mix. See for details http://msdn.microsoft.com/en-us/library/cc645032%28v=vs.95%29.aspx for details.

Muhammad Qasim Hunain
  • 79
  • 1
  • 1
  • Thanks for the reference to the article. We already have this in place, the problem is that we cannot even establish the connection to the server to be able to download the policy file. – GPicazo Dec 26 '16 at 21:56
0

According to the description of the problem as well as comments and the article "Relaxed Cross-Domain Access Restrictions", I think that most likely, the problem is with access restriction when the application is run in "in-browser" mode.

To verify that your application is run with trusted privileges you can check that property Application.HasElevatedPermissions is true.

Also, try to follow this guide How to: Enable Trusted Applications to Run Inside the Browser

Make sure that your server's firewall does not block "policy server" port 943

If you still unable to connect to server, try to change port that your service work on to some port that in range 4502 to 4534.

Yuriy Tseretyan
  • 1,676
  • 16
  • 17
  • Accepting this answer because I believe, based on the possible suggested solutions that have been discarded as not applicable, that the issue is most likely due to access restrictions that have not been thoroughly or correctly verified. Will update the post once the issue is resolved. – GPicazo Dec 27 '16 at 23:44