469,903 Members | 2,210 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,903 developers. It's quick & easy.

advanced .net remoting questions

1.communication between the client and server has to go thru client and
server channel sinks before its turned to object method invokations
those channel sinks carry messages thru and other header informations
now how can u secure those header information like the requestheaders
from being modified during its way to the server say by a third party
that acts illegaly to those information?
2.what are the header information that gets added to our header
collection from the formatter sinks from client and server sides?

3.what type of objects that get stored inside our streams ?


*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 15 '05 #1
3 3228
If you create a custom sink (you'll need one for the server and one for the
client), you can change the headers and/or the actual stream content.
One simple solution is to take the serialized object info, and create a
message digest (see the RSA/DSA classes in System.Cryptography). You then
add the message digest to the headers, and read on the other side. On the
other side, perform the same digest operation, if the digest in the header
matches the one you just created, the message wasn't tampered with.

A slightly stronger mechanism, although one that is a bit more complicated
is to change the stream contents itself (instead of adding message headers).
Take the data after it's been serialized and create a message envolope. This
requires that both client and server create key pairs and share public keys
ahead of time. You can then sign the message, as well as create a symmetric
cipher key, encrypt the entire stream, encrypt the symmetric key with the
other party's public key, and send it (either as part of the stream, or in
the header). On the other side, your custom sink will decrypt the symmetric
cipher key using it's private key, decrypt the message, and validate the
digital signature.
As a slight modification to this technique, you can negotiate a symmetric
key between the two sides ahead of time instead of generating and sending a
new one each time. You can either do this by encrypting a symmetric key with
the other side's public key and sending it ahead of time (only once), or you
can have both sides derive the symmetric key using an algorithm like the DH
key exchange.
Each approach has it's pros and cons when it comes to security. In one
senario, you are sending the key only once. If an attacker can somehow grab
and crack this key, he can read all the messages. Sending a new key with
each message inside a digital envelope keeps the encryption unique for each
message, so one key cannot decipher all messages, but you are sending the
key with the actual message (and there is always a chance someone can
decipher the encrypted key itself).

Note that in all three scenarios, the major component is the message digest
(which is also part of the digital signature if you decide to do that). The
digest, if using the proper keys, will always be the same on both sides if
the message hasn't been tampered with while in transit.

-Rob Teixeira [MVP]

"Paul Fi" <na*******@hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
1.communication between the client and server has to go thru client and
server channel sinks before its turned to object method invokations
those channel sinks carry messages thru and other header informations
now how can u secure those header information like the requestheaders
from being modified during its way to the server say by a third party
that acts illegaly to those information?
2.what are the header information that gets added to our header
collection from the formatter sinks from client and server sides?

3.what type of objects that get stored inside our streams ?


*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

Nov 15 '05 #2
ok may be i have to be more specific to what on my 1st question now for
question 1 lets assume that our sent stream is actually encrypted in
some way but there are the IMessage (used for reference) and the request
headers send with the encrypted stream to the server now what my
question should sound like is if a third party get hold of my request
sent to the server the third party might not be able to modify the
stream coz its encrypted but what about the request headers that are
sent along with the stream if that can be modified perhaps then
information like Client's IP Address might be changed, is that actually
possible if so then how can we prevent such scenario?

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 15 '05 #3
It's been a while since I've dealt with remoting, but at some point, before
the transport sink, both the message itself and the header get dumped into a
flat stream (by using the serialization overload that takes both an object
graph and a headers collection by default). If you replace this sink (and
its counterpart on the other side), or replace the stream it produces with a
digital envelope content stream, it should work. By the way, please use
punctuation - that makes it much easier to understand what you are trying to
convey :-)
If you need more help with this, try the
microsoft.public.dotnet.framework.remoting news group. Ingo is usually
there, and he usually has good answers. In fact, he has written a book about
remoting and has a very good site with examples http://ingorammer.com/

-Rob Teixeira [MVP]

"Paul Fi" <na*******@hotmail.com> wrote in message
news:u%****************@TK2MSFTNGP12.phx.gbl...
ok may be i have to be more specific to what on my 1st question now for
question 1 lets assume that our sent stream is actually encrypted in
some way but there are the IMessage (used for reference) and the request
headers send with the encrypted stream to the server now what my
question should sound like is if a third party get hold of my request
sent to the server the third party might not be able to modify the
stream coz its encrypted but what about the request headers that are
sent along with the stream if that can be modified perhaps then
information like Client's IP Address might be changed, is that actually
possible if so then how can we prevent such scenario?

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

Nov 15 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by AMDRIT | last post: by
6 posts views Thread by Palvinder Singh | last post: by
7 posts views Thread by hardieca | last post: by
2 posts views Thread by Wimpie van Lingen | last post: by
1 post views Thread by Waqarahmed | last post: by
reply views Thread by Salome Sato | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.