What is the best protection against a "chosen-ciphertext" attack when transmitting (=streaming) secured (=crypted) data via networks using the TCP protocol?
Firstly, a little crypto background. I'll provide you with links and you can decide how far you read.
The key to avoiding CCA/CCA2 (Chosen ciphertext attacks) is to not provide an "oracle" (something the attacker can query either in a limited fashion or at will). In terms of practical implementations of such oracles, replying to encrypted email messages with the stuff you previously decrypted is an example of providing an oracle - whatever ciphertext went in has been decrypted and provided to the attacker. , a m
The key is to not provide that oracle, to which there are two solutions. One is to encrypt-then-mac - i.e. use a pre-shared secret to produce a message authentication code which the recipient can check before decrypting. That way, if the ciphertext is not from the sender, you reject it. An alternative to this is to use an authenticated encryption mode, a complete, integrated approach (it combines your block cipher with a MAC).
So the approach to solve the CCA/CCA-2 problem is to use some kind of authentication of your messages.
What can you do now? Read about the protocols your ciphers use and ensure they use something like EAX, or a MAC.
First of all, it's worth to analyze whether this relatively difficult attack is indeed a risk or threat for your system and specific setup. If you could provide a bit more details, it would be easier to give an advice in this respect.
In general, the best protection against the chosen-ciphertext attack is to make impossible for an attacker to both 1) insert encrypted pieces of data, especially large amounts of them and 2) review the decrypted versions of the data they inserted.
Transmission of the encrypted data over SSL could help to prevent insertion of the data in the stream since it would guard against man-in-the-middle attack. Another defense is to detect invalidly encrypted message (for example, with checksums or digital signatures) and in case of checksum validation or decryption failure, avoid providing to the attacker the decrypted version of the data - this way even if the attacker manages to insert ciphertext, he would not be able to use your application as a "decrypting oracle".
First off, don't design your own cryptographic protocol! Please don't be offended, but: if you have to ask this kind of question, you are not qualified to design cryptography. (Frankly, even I would try to avoid designing a cryptographic protocol, even though I am qualified.)
I know some other answers have suggested you go learn about IND-CCA2 and authenticated encryption and encrypt-then-mac and digital signatures and checksums and stuff like that, and then (presumably) go implement your own crypto. Personally, I think that's a bad idea. There are many opportunities to screw something up, so I think that's a dangerous approach. Fortunately, it is not necessary to design your own crypto -- there are good schemes out there that have been vetted carefully by many experts, over a period of years. You can just re-use them.
Therefore, instead of trying to design your own crypto, I strongly recommend you try hard to reuse some existing, well-vetted scheme. For communication security, I recommend TLS. For protecting stored data, I recommend GPG with signed, encrypted messages (or other software that supports the OpenPGP format). This way, you don't even need to know how to protect against chosen-ciphertext attacks; you just need to do know that TLS and GPG already protect against them for you.
Isn't it great? You get both strong security, and you don't have to do any hard lifting yourself; someone else has already done all the hard work. It's a win-win all around!