We Keep Coding

Server and Client Secure Identification without SSL

I'm currently developing a C# application that communicates between a client and server using TCP/IP. After connecting I'm swapping session based RSA public keys to then pass a session based AES symmetrical key. This all works fine and means I have a secure channel to communicate on.
The trouble now is that I need to ensure that the server and client are both the ones I wish to communicate with. Before anyone suggests SSL/TLS: I'm not connected to the Internet to allow the use of a root CA.
Would it be valid, that after establishing a secure channel between the client and server that I provide a simple challenge-response method? For example, if the client sends an identifier (GUID?) the server compares this value to known clients and accepts or rejects it, and the same is repeated in the opposite direction. As the data is encrypted and the encryption is session based is this a valid method of verification?
I understand that the storage of these identifiers is the weak point.

Before anyone suggests SSL/TLS: I'm not connected to the Internet to allow the use of a root CA.
Before you are re-inventing the wheel: you don't need root CA with SSL/TLS but can simply use self-signed certificates with key pinning. Public root CAs are only usually used because it scales much better to provide only few common CAs instead of exchanging all self-signed certificates (or their fingerprint) to all peers of the communication.
Apart from that it looks like you proposal assumes a secure connection already to check credentials which you then will use to verify that the connection is really secure. Or in short: to provide a secure connection you need a secure connection first.

Configured SSL on Apache Tomcat 7.0.47

Have implemented SSL with self-signed certificate On Apache Tomcat 7.0.47 using Java keytool.exe.It's working fine in Browser.
Issues are:
1) while invoking the API's in java/dot net client am getting exception as "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel"
Solutions i got through online are:
1) Need to ignore invalid certificates then what's the use of SSL implementation.
2) Need to import cert into client truststore.
Could anyone suggest me how to solve this problem,is anyother ways to implement SSL and invoke those API's in client application. don't want to ignore the Cert
It's working fine in java client using InstallerCert.java class but need to invoke HTTPs API's in dot net client,any help would be really appreciated
Thanks in Advance

You need to establish trust relationship between client and server, in order to call server APIs. For java you can follow these steps to achieve your goal -
Generate certificate for server (You can do this by using installCert.java)
Once this certificate is generated usually it will be keystore file and/or .cert file
You copy this file(s) into your JAVA_HOME/lib directory
Then restart your server and this should be done
More info can be found from these sources -
security-ssl-certificate-error-use-your-trusted-certificate and http://miteff.com/install-cert
Hope this helps. There are other ways also, to generate certificate but this way is easiest as per my understanding. :-)

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# - SSL with Websphere MQ version 7.0.1

When connecting to an SSL enabled queue manager using C#, what values do I need to set to get the queues to work?
I currently get this error:
Reason Code: 2393
MQRC_SSL_INITIALIZATION_ERROR
In my code I am setting the MQEnvironment.SSLKeyRepository and MQEnvironment.SSLCipherSpec
Is there something else I need to set with C# to make this work? I have seen some Java examples that set keystore passwords and types and things.
I have also seen examples setting system environment variables too, but that hasn't seemed to make any difference either.

The general pattern for debugging WMQ SSL is as follows...
Get the application to connect using no SSL. This eliminates problems with connectivity, wrong queue or queue manager names, etc.
Get SSL working with server-only authentication. This means setting SSLCAUTH(OPTIONAL) on the SVRCONN channel. The QMgr will present a certificate that the application must trust but the application does not need to authenticate back to the server. This validates that both the application and the QMgr can access their keystores and that the QMgr's certificate or CA chain are properly loaded in the app's keystore.
Finally, set SSLCAUTH(REQUIRED) in the SVRCONN channel so that the application authenticates back to the QMgr. At this point the only possible problems are that the QMgr doesn't trust the app's cert or CA.
If the connection attempt is refused by the QMgr, the errors at the client will purposely be cryptic. The detailed messages will be found in the QMgr's AMQERR??.LOG files. If the failure is at the client, these messages will be found in the client's error logs or you can enable trace.
Enable trace using the strmqtrc command and stop it with endmqtrc. The WMQ Clients manual has a section describing where client trace files end up and another section dedicated to tracing on Windows in general. This can be very useful in determining client-side configuration problems such as failing to find a private key, failing to find a keystore, etc.
In your case, the 2393 indicates that something in the client configuration is failing. Since you are no longer getting the error with the keystore password, I'm guessing it may be having problems finding a private key or not trusting the cert provided by the QMgr. In the first case, setting SSLCAUTH(OPTIONAL) will work because the client' won't need it's private key. However if the problem is trusting the QMgr or other configuration issues, SSLCAUTH(OPTIONAL) won't help but tracing should sort that out.
Incidentally, the need to trace and diagnose on the client side is why IBM does not support client installations where the jars or libs were copied over rather than running the full client install. Although you can get the client to run by copying a few lib files and classes, this does not provide all the facilities for tracing and diagnostics. If you have not performed a full client install, some of what I've described here will not be possible. If that is the case, download and install the client from SupportPac MQC7.

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.