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.
Related
Why a service certificate is required when non-windows client credential specified ?
(i found some specifications on the book said that, a service certificate can be used to negotiate a symmetric key for messaging encryption and signing when negotiation is enabled, but if negotiation is disabled, the client must reference the certificate in the store or including the BASE64 encoded public key, it comes out another question as below)
when the negotiation is disabled, definitely the service certificate will be used for encrypting message, because the client knows the public key, but which one will be used for message signing ?
when the transport security is enabled, and the service certificate is also specified, it said that the certificate will be used for negotiate a SSL session key for message signing and encryption, it applied to all the bindings ,such as HTTP, TCP, etc.
when we are using the windows client credentials, which one will be used for message encryption and signing?
thanks.
IF you choose to authentucate the client you can choose between windows credentials, username, certificate or SAML token. If windows auth is not available you need some other mechanism.
As for the other questions please be more specific. In general client will generate a temporary key (session key) which will be used to encrypt the message. Server certificate will encrypt the session key.
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
If one way SSL is used (Server Certificate authentication) then data sent from client gets encrypted using Public key of the server certificate. So privacy protection is available for data sent from client. My questions are
Does this mean that in One way SSL data sent from Server to client is not encrypted and sent as plain text ?
For both server to client and client to server communications the data/message is not signed and so tamper protection or data integrity is not assured. Are there any other means to achieve data integrity while using SSL based transport security and not Message security options ?
One way SSL just means that the server does not validate the identity of the client. It has no effect on any of the other security properties of SSL.
While the SSL protocol is a bit complex, the basic gist of what happens is this: The client generates a random key, encrypts it so that only the server can decrypt it, and sends it to the server. The server and client now have a shared secret that can be used to encrypt and validate the communications in both directions.
The server has no idea of the client's identity, but otherwise, the encryption and message validation is two way.
Update:
1) Yes, encryption both ways is symmetric and uses a shared secret generated during session setup.
2) With a shared secret, message integrity is trivial to assure. You just ensure the message has a particular form. For example, I can prefix every message I send with a sequence number and append a checksum onto it before encryption. You decrypt it with the shared secret and validate the sequence number and checksum. How can an attacker substitute or modify the message without knowing the shared secret and still keep the sequence number and checksum intact?
In SSL, two things happen:
First, a session key is negotiated using something like the
Diffie-Hellman method. That generates a shared session key but never
transmits the key between parties.
Second, that session key is used in a normal symmetric encryption for
the duration of the connection.
SSL does use public/private in one way, because an X509 certificate is
used to identify at least one end of the connection. Those certs are
signed using an asymmetric key pair.
Extracted from How can SSL secure a two-way communication with only one key-pair?
Mostly, my confusion seems to be eminating from my attempts to understand security within the context of WCF. In WCF, it looks like certificates can be used for the purpose of authentication, as well as encryption. Basically, I am trying to understand:
How can an X509 certificate be used as an authentication token? Aren't ssl certificates usually made to be publically available? Wouldn't this make it impossible for them to be used for authentication purposes? If not, are there some protocols which are commonly used for this purpose?
When encrypting messages with WCF, are certificates used which have been issued only to the client, only to the server, or to both? If certificates from the client and server are both used, I'm a little unclear as to why. This mostly stems from my understanding of https, in which case only a certificate issued to the server (and chained to some certificate issued by a root CA) would be necessary to establish an encrypted connection and authenticate the server.
I'm not entirely sure this is the correct forum. My questions stemmed from trying to understand WCF, but I guess I would like to understand the theory behind this in general. If it's a good idea, please suggest the correct forum for me. I'd be happy to try to get this question migrated, if necessary.
Thanks in advance!
Well this is pretty complex question. I will try to explain some parts but avoiding as much detail as possible (even after that it will be pretty long).
How does authentication with certificate work?
If a holder of the private key signs some data, other participants can use the public key of the signer to validate the signature. This mechanism can be used for authentication. Private and public keys are stored in certificate where private key is kept safe on the holder machine whereas certificate with public key can be publicly available.
How does it relate to HTTPS?
WCF offers transport and message security. The difference between them is described here. The transport security in case of HTTP is HTTPS where only server needs issued certificate and client must to trust this certificate. This certificate is used both for authenticating server to the client and for establishing secure channel (which uses symmetric encryption).
HTTPS also offers variant called Mutual HTTPS where client must have also issued certificate and client uses the certificate to authenticate to the server.
How does message security work and what is a purpose of two certificates in that scenario?
In case of message security each message is signed, encrypted and authenticated separately = all these security informations are part of the message. In case of SOAP this is described by many specifications but generally you are interested in security bindings and X.509 Token profile.
Security binding is part of WS-SecurityPolicy assertions and it is describes how the message is secured. We have three bindings:
Symmetric security binding - symmetric encryption
Asymmetric security binding - asymmetric encryption
Transport security binding - assertion that message must be send over HTTPS or other secured transport
X.509 Token profile specifies how to transport certificates (public keys) in messages and how to use them.
Now if you have symmetric security binding you need only server certificate because
When client wants to send message to the server it will first generate random key.
It will use this key to encrypt and sign request
It will use service certificate to encrypt derived key and pass it to the request as well.
When the server receives the message it will first use its private key to decrypt that key.
It will use decrypted key to decrypt the rest of the message.
It will also use the key to encrypt the response because client knows that key.
Client will use the same key generated for request to decrypt the response
This is symmetric encryption which is much more faster then asymmetric encryption but key derivation should not be available in WS-Security 1.0. It is available in WS-Security 1.1. HTTPS internally works in similar way but the key is the same for the whole connection lifetime.
If you have asymmetric security binding you need two certificates:
Initiator must have its own certificate used to sign requests and decrypt responses
Recipient must have its own certificate used to decrypt requests and sign responses
That means following algorithm
Initiator encrypts request with recipient's public key
Initiator signs request with its private key
Recipient uses initiator's public key to validate request signature
Recipient uses its private key to decrypt request
Recipient uses initiator's public key to encrypt response
Recipient uses its private key to sign response
Initiator uses recipient's public key to validate response signature
Initiator uses its private key to decrypt response
The order of signing and encrypting can be changed - there is another WS-SecurityPolicy assertion which says what should be done first.
These were basics. It can be much more complex because message security actually allow you as many certificates as you want - you can for example use endorsing token to sign primary signature with another certificate etc.
The certificate only has the public key of a public/private key pair. It does not have the private key -- this is separate from the certificate proper. When you connect to an HTTPS server, you can trust that the server is the owner of that certificate because the server must be holding the private key (and hopefully nobody else has it) because otherwise the SSL connection is not possible. If the server did not hold the private key that pairs with the public key of its certificate, it could not present you with a valid SSL connection.
You then can decide whether or not you trust that particular certificate based on one or more certificate authorities (CA) that have signed the chain of certificates. For example, there may be just one CA that has signed this certificate. You have a trusted CA root certificate locally, and so you know that it in fact was your trusted CA that signed that server certificate, because that signature would not be possible unless that CA held the private key to the CA certificate. Once again it is merely holding the private key, in this case that proves who signed the certificate. This is how you can trust the certificate.
When you present the optional client certificate on the SSL connection, the server can trust you because 1) it can see the CA (or CA's) that sign your client certificate, and 2) it can tell that you have your private key in your possession because otherwise the SSL connection would not be possible. So it also works in reverse for the server trusting the client.
You can tell that everybody is honest if you trust that the server and client are keeping their private keys private, and if you trust the source of your root certificates that sign the server and client certificates (or chains of certificates.)