I am working with a WCF service with mutual SSL security and I want to check my understanding of what certificate is used when.
Is this correct?
Client hands the server the client public certificate
Server hands the client the server public certificate
Client sends request encrypted using the server public certificate
Server decrypts request using the server private certificate
Server sends response encrypted using the client public certificate
Client decrypts response using the client private certificate
Or does it work in some other way?
RFC 2246, Section 7.4 details the handshake. Other versions of SSL/TLS work pretty similarly with regards to your question.
SSL/TLS involves two types of encryption. Asymmetric-key encryption and Symmetric-key encryption. The certificates are used for asymmetric-key encryption, and are used solely in the handshake process.
The encryption used by the certificates is very brief in time, used in the handshake. The server public/private key pair (asymmetric keys) is used to protect the session key (symmetric key). The client public/private key pair is used to prove to the server that the client is who it says it is. It knows this because the client is able to encrypt data (data known by both sides) using the client private key (that only it knows) and the server may decrypt it using the client public key.
For the ordering, I've bolded the parts of your question in the summary list below. Here's a nice summary from MSDN:
The TLS Handshake Protocol involves the following steps:
The client sends a "Client hello" message to the server, along with the client's random value and supported cipher suites.
The server responds by sending a "Server hello" message to the client, along with the server's random value.
The server sends its certificate to the client for authentication and may request a certificate from the client. The server sends the "Server hello done" message.
If the server has requested a certificate from the client, the client sends it.
The client creates a random Pre-Master Secret and encrypts it with the public key from the server's certificate, sending the encrypted Pre-Master Secret to the server.
The server receives the Pre-Master Secret. The server and client each generate the Master Secret and session keys based on the Pre-Master Secret.
The client sends "Change cipher spec" notification to server to indicate that the client will start using the new session keys for hashing and encrypting messages. Client also sends "Client finished" message.
Server receives "Change cipher spec" and switches its record layer security state to symmetric encryption using the session keys. Server sends "Server finished" message to the client.
Client and server can now exchange application data over the secured channel they have established. All messages sent from client to server and from server to client are encrypted using session key.
The WCF request/responses will all be after the client/server have switched to using the session key (symmetric key) for encryption. It won't be using the certificate private/public keys at this point.
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've been looking for information about SSL certificates and encryption protocols. I got very good answers, especially on this website.
There's only one thing I don't get. If I got this right, the verification of the identity (I mean the verification of the server identity, not the certificate identity) is made using asymmetric cryptography.
That means the steps would be (stop me if I'm wrong):
Client uses verified public key to encrypt a random challenge string and send it to server.
Server decrypts it using its private key and sends it back to the client.
Client checks if the response from server matches the random challenge string it just sent.
What prevents a fake server to do it like this, with a real certificate for, say, www.example.com but without having the private key?
Client uses verified public key to encrypt a random challenge string and send it to server.
Fake server sends the encrypted random challenge string to www.example.com, as a client wanting to check its identity.
www.example.com sends back the decrypted random challenge string to fake server.
Fake server sends it back to client.
Identity is confirmed?
Client uses verified public key to encrypt a random challenge string
and send it to server.
The key exchange mode where the client encrypts something with the server's public key is the RSA key exchange mode. There's a full description of it in section F.1.1.2 of the TLS specification.
Essentially, the client generates the pre-master secret, encrypts it with the server's public key (found in the server certificate the server has sent), and sends it to the server (in a Client Key Exchange Message). That's it. Only the server with the matching private key can decipher it. The server doesn't send any deciphered version back to the client, so couldn't ask for a 3rd party to do whatever operation you seem to have in mind with it.
This is just a straw-man argument. The steps you have listed are completely imaginary. The actual steps are:
The server sends its certificate as part of the TLS handshake.
The server sends a digital signature over its certificate and the other handshake messages, signed by its private key.
The client uses the public key in the certificate to verify the digital signature.
Only a server that has the private key corresponding to the public key in the certificate can succeed.
I suggest you do some reading, and not of random postings on the Internet: try the normative reference: RFC 2246.
I have some simple questions that i can't get a direct answer in any site because the variety of options in this subject.
In Message Level Security, is mandatory for the client to have an installed certificate? I assume this because the server should encrypt the response message with the client Public Key and then the client decrypt it with his own Private Key.
Is any alternative to not have the certificate in the client and have the messages encrypted in both ways(client->server) and (server->client)?
You can have message security without the client authenticating at all. You only need a client cert if the client is authenticating via certificates
The server cert is used for securing the message in the first case. The client encrypts with the public key of the server and the server can then decrypt with its private key
If you are using secure conversation then the server cert is just used to bootstrap a session key which is then used for encryption/decryption
As long as the server cert has a full chain of trust in the client then there is no need to install the server cert on the client either
Can any one explain me, what exactly the role of Service Certificate and what exactly it does in this Combination (Message Security - Client: UserName Validator, Server: Server Certificate)..
If you can explain me step by step, it'll be really helpfull.
Thanks in advance
Service certificate is used as key artifact to establish secure channel between client and server.
When client starts communication with server it first validates that certificate is trusted (it must be either installed in clients certification store or it must be issued by the authority the client trusts to). This validation should ensure that client communicates with the right server it trust to.
My understanding of using service certificate for securing messages is:
The client creates derived key used to encrypt and sign the request message with symmetric security. Service will need the same key to decrypt the message and validate the signature so the client must pass the key within the message. The key is encrypted with service's public key passed in the certificate because only holder of the private key (the server) can decrypt this derived key and then decrypt the request message itself.
The service uses decrypted derived key to encrypt and sign the response message and pass it back to the client. The client remembers its derived key used to send the request so he can also decrypt the response.
The same process is used for the next exchange but client creates a new derived key for each request.
User name and password are only data passed in the message used on the server to validate that user can use the service.
I know that certificates that are sent by the server cant be faked (still there is MD5 collisions but costy) but what about faking the client ..
in man in the middle attack:
cant we tell the server that we are the legitimate client and take data from that server manipulate it then encrypt it again with legitimate client public key ? how does the client be sure that the data came really from the server ?
in theory .. can we inject any data into the response sent by the server to the client ?..
How are you authenticating the client? SSL client certificates? Or some application level system (cookies etc)?
Here's what SSL does in a nutshell:
Negotiates a Diffie-Hellman shared session key between the two parties
Has the server sign the session key and send the result to the client. Once the client verifies this, the client knows there is no MITM, and the server is who they say they are.
If client certificates are enabled, has the client sign the session key and send the signature to the server. The server now knows there is no MITM and the client is who they say they are.
Encrypts all data in both directions using the shared session key
Typically when you use SSL you won't use client certificates. Strictly speaking, the server does not know if the connection is MITM'd. However, most clients will disconnect if the server certificate is bad. The server assumes that if the client pushes forward with the connection, there is no MITM. Even if Mallory, doing the MITM, chooses not to propagate the disconnect from the client, he has no new information now; all he's done is connected to the server himself. Without intercepting the client's session cookie or other authentication information (which is only sent by the client after verifying the connection is secure) the MITM is useless.
So in short, as long as one end or the other verifies the certificate of the other end before initiating any high-level communication of sensitive information, SSL is secure in both directions.
You're right -- without secure certificate authentication on the client and server there is an opening for a man in the middle attack.
SSL can be "secure both ways" if you use mutual authentication also called two-way SSL.