I'm writing a client/server that will allow Customer Data to be shared between our head office and on-the-move sales folks within the company.
The server downloads and writes the customer data in XML files but also keeps the data in memory so that it can act as a local client as it were.
I'm planning to Serialize the ArrayList so that the customer data can be easily sent across the internet. How secure is this? Should I look into some form encryption before I transmit the Serialized object?
I wouldn't perform the the encryption as part of the Serialisation.
There are two issues here:
1 and 2 are separate problems and combining them into a single solution will only create problems for yourself in future.
I would use out of the box Serialisation and then use a secure transmission channel, like TLS.
You shouldn't think about the serialization part. At the end of the serialization process, you get data (either binary or XML) and you should treat that as unsecure.
If your plan is to securely transfer it over the web, you should look into HTTPS, but if you plan to transfer it over other means like email or file transfer or you need to securely store it or archive it, you should probably look into PKCS#7 and related standards.
I'm planning to Serialize the ArrayList so that the customer data can be easily sent across the internet. How secure is this?
As secure as printing it on postcard and putting it in the mail. Anything in the chain between you and the receiver can see the content.
Should I look into some form encryption before I transmit the Serialized object?
That is the usual approach. Either transport level security, such as secure sockets, where the connection between client and server are encrypted, but the message appears in 'plain text' at either end, or you can encrypt the message itself, and then decrypt in the client. Encrypting the message rather than the transport is more complicated, as it effects more layers, but allows you to save messages or change from a client server to something which allows caching. If you are worried about the information becoming lost if the on-the-move folks lose a laptop, then encrypting the messages and decrypting them only on use may be better. (the other alternative is to encrypt the drive any customer message is saved on, which protects everything, but also effects everything on the computer so requires a change in company IT policy).
You can of course use all three at once.
Use HTTPS or TCP over SSL depends on your communication channel. If it requires securely deploy your certificates in each side and everything in it will be secure.
Also as you said encrypting before serializing will do the trick, you can use one secret key in both sides, you need to store the keys safely and ensure no can reach them. However this is not great because you might want to replace them later and key management can be a little bit pain. I'd say stick with HTTPS/TCP + SSL
I'm planning to Serialize the ArrayList so that the customer data can be easily sent across the internet. How secure is this? Should I look into some form encryption before I transmit the Serialized object?
Encryption shouldn't happen at the serialization step. To be clear: serialization is taking the object and turning it into a string of bytes. All your serialization should be done in-the-clear without any unnecessary munging in there to complicate things.
Encryption should happen once the package of bits is ready to be exported. If you're communicating "live" with the destination--such as over the network, then you should use SSL to secure the line. Luckily, this is as simple attaching an SslStream (MSDN) to your TcpClient. Note that encrypting just a small package of bits within a larger (unencrypted) stream is generally false-security. To be safe, the whole conversation should be secure.
If, on the other hand, you're storing the bits (i.e. in a file), then you should use some sort of offline encryption. Again, the .NET framework handles all the details for you; just attach a CryptoStream object to your FileStream and you're done.
Serialize, gzip, then send over HTTPS. It's important to keep these steps in the proper order. Compressing encrypted data doesn't work. Encrypting uncompressed data takes more time, and in theory reduces security.