advanced .net remoting questions

  • Thread starter Thread starter Paul Fi
  • Start date Start date
P

Paul Fi

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 ?
 
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]
 
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?
 
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]
 
Back
Top