I have a small question about SSL implementation with Transport security in wcf.
What i understood from Research is,
First client makes a request to WCF via https.
Server will send a public key to client.
Client uses this public key and encrypts the data and then sends across transoport.
server receives the encrypted data and decrypts it using private key.
Is there anything wrong in my understanding......?
My second question is
Whats the process when service sends the response back (how encryption and decryption occcurs?).
Thanks in advance
Note: My Question is not about how to implement SSL in WCF, it is how ssl workds both in case of request and response.
Related
I have to make an WCF client for one external SOAP web-service written probably in Java. That web-service uses WS-Security for signing and encryption (so, I suppose I have to use WCF message level security). Transport mechanism between client and web-service is HTTPS with 2-way handshaking.
The problem is that I have to use four different certificates - let us call them CertA, CertB, CertC and CertD.
CertA and CertC must be used for signing the SOAP message.
CertB and CertD must be used for SOAP message encryption and HTTPS handshaking.
Basically, the client is supposed to sign a message using it's private key and encrypt the message using server's public key. The server do the opposite.
Precisely, here's what WCF client have to do in order to send a message to the server and receive the response back:
Client sign SOAP request with certificate CertA (using CertA's
private key)
Client encrypt SOAP request with certificate CertD
(using CertD's public key)
Client send signed and encrypted SOAP message over HTTPS to the server (certificate CertB is required by the server during HTTPS 2-way handshaking for authentication purpose)
On the server side:
Server receives the message, authenticate and authorize client
Server decrypt message with CertD's private key
Server verify message signature with CertA's public key. Server then process decrypted and verified message.
Server create response message and sign it with certificate CertC (using CertC's private key)
Server encrypts the response message with certificate CertB (using CertB's public key)
Server send response back to the client over HTTPS transport.
When client receive the server response:
Client decrypt response with its CertB's private key
Client verify message signature with CertC's public key
Client process the response.
The question is how to configure such WCF client? Which binding to use to enable SOAP signing & encryption on message layer + HTTPS 2-way handshake on the transport layer and how to "tell" WCF what's the purpose of each of the 4 certificates?
(Yes, I already saw this article: https://msdn.microsoft.com/en-us/library/ms729856(v=vs.110).aspx but I'm afraid that article doesn't provide solution for my case because they use some weird duplex binding which require a client to open an listening port and that's not an option for me since I have to use regular HTTPS connection).
I have created a WCF service with X.509 certificate. I took a reference from this article: http://www.codeproject.com/Articles/36683/simple-steps-to-enable-X-certificates-on-WCF. Now it requires a certificate to be sent along with request to the server in order to access the service. My question is that does using a X.509 certificate in request encrypt the message to be sent to the server or do I have to do anything more to do it?
A client sending a request to a WCF service should only require a public key to start off. If you have your service (and client) configured correctly, WCF should automatically handle the authentication / encryption before the transmission of your request content.
As I understand it, your client does not need a X509 cert.
I have seen one or two questions about this but no definite answers. I have a customer requirement to implement a WCF-based client/server solution using Message Encryption AND HTTPS. I understand that WCF doesn't support this as standard, and the options are HTTP with Message Encryption, HTTPS without Message Encryption, or HTTPS with Message Credentials.
None of these will satisfy the customer requirement. I have control over both the service and the desktop-based clients. The service is hosted at my location and the clients access it over the internet.
I have dug around for days (and nights :( ) trying out custom bindings and so on, but whenever I try to combine message encryption with Https, I come up against this error:
"The binding contains both a SymmetricSecurityBindingElement and a secure transport binding element. Policy export for such a binding is not supported."
I would prefer to user username/password for authentication but I am prepared to use client certificates if this makes it possible. So far I haven't found any combination which is acceptable to WCF.
Is there any way to achieve this or am I just wasting my time? I would value a quick answer because my customer's deadline is drawing very near!
Thanks!
According to this, the special both mode for security (meaning both message and transport) is only supported in the NetMsmqBinding binding, which I'm guessing, is not an option for you. Does your client happen to be the NSA? (Just wondering why anyone would need their communication encrypted twice).
OK I've found a solution ...
Using IMessageInspector I intercepted the incoming and outgoing messages so that they can be encrypted and decrypted. Encryption uses a symmetric technique - best because asymmetric only allows encryption of short strings and is very slow.
The downside is that both ends need to have the private key of the certificate - so the cert needs to be installed on both client and server machines (or the key could be placed in config). This works for me though because the number of users is limited and all are under the control of the IT dept.
If I had more time I would have looked at setting up a second SSL connection with a different cert, purely to handle the certificate negotiation and avoid placing the cert on the client machine. Using SslStream was a possibility but I wasn't sure whether I could access key information to use for my own encryption, or whether this is held privately within SslStream class.
For now I'm just pleased to have it working before my deadline (only just though :) ) ...
This question is in context of web-services. If I invoke a web-service over SSL alongwith the required data for the service; I get an SSL error, if the SSL cert is invalid, and I wont make further requests. But what happened to the data I sent in the first request ? Will it be transmitted to the attacker ? Can he decrypt it ?
In a typical website this scenario hardly arises, as our request to server has hardly got any private data - once the server sends some form, only then we proceed with confidenial data.
Thanks.
SSL/TLS is established before any data is sent. Consequently if there was an error, nothing is sent and your data is safe.
is there a way for some one to sneak in the to see data if my service is over http and the caller in my case is hosted on http (i.e. service is on secure ssl host while caller is on simple http).
is that call secure or not?
Basic HTTP without any encryption or other means of obfuscating your content is just plain text going over the wire. Anyone with a bit of knowledge can trap that connection and just read everything that goes on.
I don't quite understand what you mean by the server is on secure host but the client is not? Either the conversation between those two is secured by SSL / HTTPS (but then BOTH ends need to participate), or not. If not - it's just clear text on the wire.
Yes if someone is able to sneak into your transmissions, they can workout if the messages are encrypted or not.
When you connect to a server marked with server side SSL (server marked with https), it sends a copy of its cert to the client (e.g. your browser) which verifies if its a genuine cert. This only confirms that the server is really what it says it is and not someone else masquerading.
This does not guarantee that no can intercept your message. They can intercept but wont be able to decrypt.