In case of using SSL the certificate server has a primary key and a public key that is published to all clients - as far as I understood. So in this case when message is encrypted by public key (on client side) only the owner of private key (which is the server in this case) has ability to decrypt it.

But I do not understand how this works the other way, I mean when the message is encrypted by private key then does it mean that whoever has the public key can decrypt it? That would mean that only the messages toward the server are secured and messages which come from the server can be read by anybody with public the key.

in my case I have web server in DMZ hosts multiple web services (WCF), the clients are non-server application (they are standalone .NET application) reaching these web services via internet using https protocol.

My server has SSL certificate issued by Versign, the point is that my client do not have any type of credential and any machine with that application (or similar app) should be able to consume the services, the point is that the information passing between client machine and server must be encrypted and signed, so this is my question is having the certificate and using the transport security enough to make sure that nobody can read the messages passing between client and server or do I have to somehow come up with some kind of ad hoc client credential and add message security. This link describes that SSL is good for Intranet and for internet message security is suggested why? what does happen if I only use SSL and no message security for the internet scenario?

  • $\begingroup$ What you're missing is that message is a symmetric key. $\;$ $\endgroup$ – user991 May 11 '15 at 21:07
  • $\begingroup$ OK, I still don't understand it, if the client does not have credential (an anonymous user) then there is no message level encryption, so you mean that this connection is not secure? $\endgroup$ – Fred Jand May 11 '15 at 21:15
  • $\begingroup$ The message level encryption uses the symmetric key(s). $\;$ $\endgroup$ – user991 May 11 '15 at 21:22
  • $\begingroup$ See How does SSL/TLS work? $\endgroup$ – cpast May 11 '15 at 21:25
  • $\begingroup$ I've already read this stuff if it was clear to me I would not have any questions. in all of these only talk about the point to point transport level security with SSL. $\endgroup$ – Fred Jand May 11 '15 at 22:30

You are missing the entire TLS protocol. The TLS protocol first establishes session keys. These can be randomly created at the client and send encrypted to the server. After that the session keys can be used to protect the data for confidentiality, integrity and authenticity. Encryption and authentication is performed in both directions.

The TLS protocol is however gravitating towards authenticated ephemeral Diffie-Hellman, which is a key agreement protocol. Ephemeral DH provides forward security, meaning that the session keys (and thus the data) stay secret even if the private key gets factored afterwards. In that case the private key is only used for signature generation to perform authentication.

  • $\begingroup$ My confusion comes from this: Link you can use transport security when your client is deployed within an intranet, as it provides point-to-point security. Message security is the preferred option for Internet scenario $\endgroup$ – Fred Jand May 11 '15 at 23:38
  • $\begingroup$ That's probably because intranet allows servers to directly talk to each other. If you have a web server / proxy running in the DMZ and an application server behind it then the transport security ends in the DMZ instead of at the server. Note that for server-server security usually both servers have one or more key pairs. For TLS this is called client authentication. TLS is not used for message security - for that XML encryption & XML signature specs are used. $\endgroup$ – Maarten Bodewes May 11 '15 at 23:56
  • $\begingroup$ nice explanation, Thanks, I updated my question to add more details, what do you think about this scenario . $\endgroup$ – Fred Jand May 12 '15 at 2:39
  • $\begingroup$ Nothing has really changed. Yes, you can create a secure channel even though only one site is authenticated by establishing session keys. The disadvantage of course is that the server doesn't know who it is talking to if it only authenticates itself. You need additional methods to do that. Simplest form of session key agreement: generate random key at client $K_{session}$, calculate $C = E(P_{server}, K_{session})$ then at server perform $K_{session} = D(S_{server}, C)$ (just as example to show how it can be done) $\endgroup$ – Maarten Bodewes May 12 '15 at 23:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.