We Keep Coding

Encryption with client,server situation?

I have a Client & Server application set, both written in C# but some client versions might be distributed in other languages in the future. I want to protect my applications.
I was looking for some kind of advice to stop just random people sending messages to a server and acting like a client, what kind of validation can I put in place?
My client applications I distribute will be obfuscated but is this enough? I'm just looking for some advice in this situation, is it wise for me to add some kind of encryption other than SSL, or am I just being over protective and over curious? Any input is welcomed & accepted.

It is impossible to determine if you are communicating remotely with "your client" or another piece of software that also knows how to communicate in the way that your client does.
What you can do is ensure that you are communicating with someone that is authorized to communicate with you by using client certificates for your SSL session.
The server proves who it is to the client and the client proves who it is to your server. The security then rests in whoever holds the private key to the client certificate (and the password for this key file).
The C# SslStream Class has support for this. Namely the AuthenticateAsClient method is relevant here.
In summary, if your software is only secure when communicating with a client you wrote, then your software isn't secure period. Instead, design your server in such a way that you can serve client requests securely. Using authentication is one of these ways.

You would want to do two things....one is look up certificate pinning. Your app will validate your SSL cert to thwart man in the middle attacks and it makes it hard to circumvent. The other is when making requests to the server have some type of user name / password block on the server side script before the server side does anything so the requests will simply be discarded by the server if they are from an unknown source.

Driving a Certificate Authority programatically (C# or C++)

I'm writing a client/server application that requires the server needs to be able to authenticate the client and also requires all comms to be encrypted.
The mechanism to provide this needs to be self contained within the server and client application and also to be fully automated (no human interaction required). SSL seems to be the best way to do this and is also something I am familiar with using.
For each client that needs the client software deploying to it, I planned to create (on the fly) an MSI installer with the application, the clients certificate (signed by the server) and private key and the servers public certificate (so the clients can authenticate the server - the server certificate could be self signed).
I can generate the key for the client and make a CSR, but don't seem to be able to find a way of actually signing the CSR and generating a certificate for the client thou. I have looked into the Win32 Crypto API, but haven't managed to find any examples of how to actually sign a CSR and get a client certificate.
I know how to do all of this from the command line with the openssl tool, but am not sure of how to do it from within an application.
Please note that making system calls out to the openssl tool and passing in the parameters I know to work is not an option as it's a huge security risk to rely on the openssl tool not being compromised in any way. Doing it this way wouldn't for fill the self contained requirement.
I am going about this the right way, or is there a better way to achieve the same thing - basically authentication of the clients connecting to the server and a way of the connecting client to authenticate the server they connect to, all encrypted.
I cannot make any assumptions about the server (or clients) having a static IP or hostname (DNS can be broken anyways), nor can I make any assumptions about any existing PKI infrastructure.
I am writing this primarily in C#.Net, but would consider writing a C++ extension to this if it gives me this functionality.
Finally this is my first post here, so if I've missed out something obvious or have been short on any details, please ask and I'll fill in the gaps :)
Thanks,
James

In C# you can use PKIBlackbox package of our SecureBlackbox product which provides all the functionality you are looking for in .NET. Maybe BouncyCastle library also includes this functionality.

You need to rethink at least part of this. What you are doing is radically insecure. The client's private key needs to be generated at the client. Otherwise it isn't private, so it cannot possibly satisfy any of the tenets of PKI,. including the purpose for which you are issuing it. You lose uniqueness and you also lose non-repudiability. These are both fatal flaws.

C# Know if server is being accessed from application

I have recently created an API on my server in PHP, but I have discovered that I shouldn't use my API directly with an API key because sensitive information like that can't be held securly inside an EXE. I did some research and people recommend creating a proxy between the API and your application, but even still that can be broken into.
I was wondering, how can I make my server know if it is being accessed from my C# application, or from another source? The reason why I want to know is to stop potential hackers accessing my gateway and using it themselves.
Thanks

SSL with a login?
There is no way for you to be certain someone is using your application to access a web service. I'm in a similar boat, and the most you can do is ensure the communication channel is secure (SSL) and use a username/password or something similar. You also have to be aware that anything done on the client's computer can be compromised. So much so, that you should pretty much assume that your application will be open source to anyone that wants it.

Is it possible to enforce web service calls from known client only?

Scenario:
A publically available Web Service that I have full control over.
But I only want this specific desktop application (my published application) to have access to the Web Service.
I could store a secret password in the desktop client, but that would be easy to crack.
Is there any known implementation that enforces this?
PKI, assymmetric keys?

If the public will have access to copies of this Desktop App, any good reverser will be able to crack it and "imitate" its transactions with the server. It doens't matter how secure is your cryptography, everything you app needs to encrypt/decrypt data is included in the binaries, so the cracker only needs to dig it out of it.
The objective of cryptography is to protect data while it is being transfered, from "middle-man" hackers, but if you have access to anyone of the peers, you can easily crack it.
Your server must never trust what comes from the client side.
[edit resuming]
Despite you cannot 100% guarantee a supposed client to your server is or isn't your App or some "emulator" made by thirdies, you can complicate things to them. Its a common practice in game anti-cheats to sometimes, randomly, make the client App a trick question like "whats the hash of your main.exe from offset A to offset B?" or "from now on packet type 0x07 swaps with packet type 0x5f". Once a fake is detected, server enter in a "silly mode", act malfunctional, and blacklist their IP/account to this mode for several hours so they cannot have sure of what their program is doing wrong.
If you detect someone is building an emulator, make them start all over again: jumble the packet type tables, cryptography tables, change some packet formats and force your clients to update. You won't see crackers bothering you for a while... LOL

WS-Security provides for X509 encryption.
Part of that implementation includes the possibility of only giving specific clients the generated public key. That way, only your selected clients can connect to the service.

The easiest way is message security using client and server certificates. The best way is to import the client certs in your server machines and hard code the client cert thumbprint in the app.config file. The other way is negotiation of certs which I haven't tried before.
If you are using IIS to host the service then client certificates using SSL is another option.
MSDN link on WCF Security.

How are server side applications created, how is client - server communication done?

I would like to have a client-server application written in .NET which would do following:
server is running Linux
on the server there is SQL database (mySQL) containing document URLs
What we want:
- server side would regularly crawl all URLs and create a full text index for them
- client side would be able to perform a query into this index using GUI
The client application is written in .NET using C#. Besides of searching in documents it will be able to do a lot of other things which are not described here and which are done client-side very well.
We would like to use C# for the server side as well, but we have no experience in this area. How are things like this usually done?
Clarifying question now based on some answers:
The thing which is most unclear to me is how client-server communication is usually handled. Is client and server usually using sockets, caring about details like IP addresses, ports or NAT traversal? Or are there some common frameworks and patters, which would make this transparent, and make client-server messaging or procedure calling easy? Any examples or good starting points for this? Are there some common techniques how to handle the fact a single server is required to server multiple clients at the same time?

To use c# on Linux you will need to use Mono. This is an open source implementation of the CLR specification.
Next you need to decide on how to communicate between server and client, from the lowest level of just opening a TCP/IP socket and sending bits up and down, to .Net remoting, to WCF, to exposing webservices on the server. I do not know how compleat WCF implementation is on mono, also I think you may have issue with binary remoting between mono and MS .Net .
I would suggest RPC style WebServices offer a very good solution. WebServices also have the advantage of alowing clients from other platforms to connect easily.
EDIT
In response to the clarification of the question.
I would suggest using mono/ASP.NET/WebServices on the server, if you wish to use c# on both server and client.
One assumption I have made is that you can do a client pull model, where every message is initiated by the client. Using another approach could allow the server to push events to the client. Given the client has the ability to pole the server regularly I don't consider this much of a draw back but it may be depending on the type of application you are developing.
Mono allow execution of c# (compiled to IL) on a Linux box. Mono ASP.NET allows you to use the standard ASP.NET and integrate into Apache see http://www.mono-project.com/ASP.NET and finally WebServices allow you to communicate robustly in a strongly typed manner between you client and your server.
Using this approach negates most of the issues raised in your clarification and makes them someone else's problem.
Sockets/SSL - is taken care of by standard .Net runtime on the client and Apache on the server.
IPAddress/ports/NAT traversal - Is all taken care of. DNS look up will get the servers IP. Open socket will allow the server to respond through any firewall and NAT setup.
Multiple Clients - Apache is built to handle multiple clients processing at the same time as is ASP.NET, so you should not encounter any problems there.

As many have already mentioned there are a number of thing that you have mentioned which are going to cause you pain. I'm not going to go into those, instead I will answer your original question about communication.
The current popular choice in this kind of communication is web services. These allow you to make remote calls using the HTTP protocol, and encoding the requests and responses in XML. While this method has its critics I have found it incredibly simple to get up and running, and works fine for nearly all applications.
The .NET framework has built in support for web services which can definitely be called by your client. A brief look at the mono website indicates that it has support for web services also, so writing your server in C# and running it under mono should be fine. Googling for "C# Web Service Tutorial" shows many sites which have information about how to get started, here is a random pick from those results:
http://www.codeguru.com/Csharp/Csharp/cs_webservices/tutorials/article.php/c5477

have a look at Grasshopper:
"With Grasshopper, you can use your favorite development environment from Microsoft® to deploy applications on Java-enabled platforms such as Linux"
Or see here
The ideea is to convert your app to Java and then run it on Tomcat or JBoss.

Another approach: use the Mod_AspDotNet module for Apache, as described here.

This Basic Client/Server Chat Application in C# looks like a kind of example which might be a starting point for me. Relevant .NET classes are TcpClient and TcpListener