Remoting: security and app.config

[Guest]

Hello, I have written a service (service A) in C# which is both a TCP server
for many clients and is also a client of another service (service B).

For service A the TcpServerChannel is configured in the app.config file with
secure=true which works fine. All the clients connect to this service using
secure TcpClientConnections.

For service B the TcpServerChannel is configured in the app.config file with
secure=false. I cannot get service A to successfully connect to service B
using a TcpClientChannel with no security. It seems that the TcpClientChannel
on service A is configured to use security even though I specify that I do
not want security on.

Is it possible to configure security for the server channel and no security
for the client channel? Can I do this in the app.config, or do I need to do
it programmatically?

Thanks,

 

[Steven Cheng[MSFT]]

Hi pinnguy,

Thank you for posting.

From your description, you're using .net remoting for communication between
multiple applciations, include client UI based application and service
applications. One of the client application will call a remote object from
service A, and they're using secured channel, and service A will call
another remote object from service B which does not use secured channel.
However, you found the service A can not correctly get the remote object
from service B, correct?

When the service A get error, what's the detailed error message of that
exception? Also, for such scenario, I'd suggest you try creating two
simplified application (not service) and test the same behavior. Then, we
can do further research against the simplified applications.

Regards,

Steven Cheng
Microsoft Online Community Support


==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.



Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Guest]

Hi pinnguy,

Thank you for posting.

From your description, you're using .net remoting for communication between
multiple applciations, include client UI based application and service
applications. One of the client application will call a remote object from
service A, and they're using secured channel, and service A will call
another remote object from service B which does not use secured channel.
However, you found the service A can not correctly get the remote object
from service B, correct?

When the service A get error, what's the detailed error message of that
exception? Also, for such scenario, I'd suggest you try creating two
simplified application (not service) and test the same behavior. Then, we
can do further research against the simplified applications.

Regards,

Steven Cheng
Microsoft Online Community Support

Thanks Steven, you have correctly restated my configuration.

Here is the error and stack trace that occurs when service A trys to open a
TCP client connection to service B:

System.Net.Sockets.SocketException Reason=An existing connection was
forcibly closed by the remote host
StackTrace=
Server stack trace:
at System.Net.Security.NegoState.ProcessAuthentication(LazyAsyncResult
lazyResult)
at
System.Net.Security.NegotiateStream.AuthenticateAsClient(NetworkCredential
credential, String targetName, ProtectionLevel requiredProtectionLevel,
TokenImpersonationLevel allowedImpersonationLevel)
at
System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.CreateAuthenticatedStream(Stream netStream, String machinePortAndSid)
at
System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.CreateSocketHandler(Socket socket, SocketCache socketCache, String machinePortAndSid)
at
System.Runtime.Remoting.Channels.SocketCache.CreateSocketHandler(Socket
socket, String machineAndPort)
at
System.Runtime.Remoting.Channels.RemoteConnection.CreateNewSocket(EndPoint
ipEndPoint)
at System.Runtime.Remoting.Channels.RemoteConnection.CreateNewSocket()
at System.Runtime.Remoting.Channels.SocketCache.GetSocket(String
machinePortAndSid, Boolean openNew)
at
System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.SendRequestWithRetry(IMessage msg, ITransportHeaders requestHeaders, Stream requestStream)
at
System.Runtime.Remoting.Channels.Tcp.TcpClientTransportSink.ProcessMessage(IMessage
msg, ITransportHeaders requestHeaders, Stream requestStream,
ITransportHeaders& responseHeaders, Stream& responseStream)
at
System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage(IMessage msg)

Here is the <channels> portion of the app.config file for service A:

<channels>
<channel ref="tcp" port="10000" secure="true"
protectionLevel="EncryptAndSign" name="tcp server">
</channel>
</channels>

Here is some code snippets showing how service A attempts to create an
unsecure tcp client channel to service B:

IDictionary connInfo = new Hashtable();
connInfo["protectionLevel"] = "None";
connInfo["secure"] = "False";
connInfo["tokenImpersonationLevel"] = "None";
IChannel channel = new TcpClientChannel(connInfo,null);

try {
ChannelServices.RegisterChannel(channel,true);
}
catch (RemotingException re) {
// ignore this, it happens when channels is already registered.
}
// agntPrxyUrl - url to remoting obj in service B
ITransferAgent agent = (ITransferAgent)Activator.GetObject(

typeof(ITransferAgent),agntPrxyUrl);
// Throw SocketException here if tcp server channel is secure.
// Works just fine if tcp server channel is secure="false"
AgentStatus as = agent.Status;

 

[Steven Cheng[MSFT]]

Thanks for your response pinnguy,

I think the problem is still on the secure setting of the channel you
registered. I've performed some local test (through 3 console apps), and we
are able to make the intermediate application serve both client and server
remoting through two channels (client and server) with different secure
setting. So let's still focus on your "service A"(which is the
intermediate app in your case, correct?).

From the code you provided, I saw that you use the following code to
initalize the no-secure channel:

========================
Dictionary connInfo = new Hashtable();
connInfo["protectionLevel"] = "None";
connInfo["secure"] = "False";
connInfo["tokenImpersonationLevel"] = "None";
IChannel channel = new TcpClientChannel(connInfo,null);

try {
ChannelServices.RegisterChannel(channel,true);
}

===========================

The ChannelServices.RegisterChannel Method's second parameter is just used
to set the "secure" setting, and it'll always override the setting you put
in the Construnctor's properties collection. So you need to pass "false"
into the "RegisterChannel" method. Here is my intermediate applicatino's
channel initialize code:

=================================
static void Init()
{
Console.WriteLine("Init........................");

InitClient();

InitServer();
}


static void InitClient()
{

Console.WriteLine("InitClient............................");


IDictionary props = new Hashtable();

props["name"] = "tcpCC1";

TcpClientChannel clientChannel1 = new TcpClientChannel(props,
null);

// do not secure the channel
ChannelServices.RegisterChannel(clientChannel1, false);


}

static void InitServer()
{
Console.WriteLine("InitServer.............................");


IDictionary properties = new Hashtable();

properties["name"] = "tcpSC";

properties.Add("port", 7777);


TcpServerChannel serverChannel =
new TcpServerChannel(properties, null);

//secure the channel
ChannelServices.RegisterChannel(serverChannel,true);


);
}

================================

Hope this helps.

Regards,

Steven Cheng
Microsoft Online Community Support


==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.



Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Guest]

I think the problem is still on the secure setting of the channel you
registered.

I made a mistake in the pseudo code I posted. I actually do have the secure
setting set to false. But it does not make any difference, I still get the
error.

I did figure out to fix it though. The problem is orginating in the channel
template for ref="tcp" in the app.config file. When this template is used, an
instance of a TcpChannel is created and registered when
RemotingConfiguration.Configure is called. Since I specified secure="true"
for this channel, the same settings where also used by my tcp client channels.

So to get around this, instead of using the ref="tcp" template, I directly
specify the type I want using type property. So my app.config channel element
looks like this:

<channel type="System.Runtime.Remoting.Channels.Tcp.TcpServerChannel,
system.runtime.remoting, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089"
port="10000" secure="true"
protectionLevel="EncryptAndSign" name="tcpServer"/>

Now it works! I can have a secure server channel and an unsecure client
channel.

 

[Steven Cheng[MSFT]]

Thanks for your response pinnguy,

Yes, you're right. As for TcpChannel or HttpChannel class, they both
implement IChannelSender and IChannelReceiver, so the runtime will pickup
the one for both server and client component. Your approach about manually
reference the TcpserverChannel and TcpClientChannel is reasonable. Also, in
my test app, I do all the channel registering programmatically (not use
config file), this also works.

Regards,

Steven Cheng
Microsoft Online Community Support


==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.



Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)