2

I am working on a HTTPS service which will be deployed on a server with a self signed certificate and a client which will accept all certificates.I am new to SSL.

I have gone through this post and this post and understand how to configure trust manager to accept all certificates.

If I understand correctly a java client will use server's public key(installed by using server's public certificate) to encrypt data to be sent to a server.And a server then uses it's private key to decrypt the data.

My questions are:

1.In a common scenario ,we install the server.cer in truststore of client machine(cacerts in java). How does the java client code links to this installed public key to encrypt data while communicating to such server? Who does the SSL encryption here? Is it Java APIs that do it or do i have to handle encryption in my client code before sending data to server?

2.As given in one of the above mentioned post ,we can make client accept all certificates.How will the encryption and decryption work in this scenario? How will the client know which public key to use for encryption as we are not installing any server specific key in client's truststore?

I am looking for more technical details.

Community
  • 1
  • 1
WillMcavoy
  • 1,795
  • 4
  • 22
  • 34

1 Answers1

3

I am working on a HTTPS service which will be deployed on a server with a self signed certificate and a client which will accept all certificates. I am new to SSL.

Clearly. You're working on an insecure system. It's a waste of time. You may as well not use SSL at all. The client should accept this certificate and all CA certificates, not all certificates. As described, your system is vulnerable to man-in-the-middle attacks.

If I understand correctly a java client will use server's public key(installed by using server's public certificate) to encrypt data to be sent to a server.

You don't. It doesn't. The certificate is used to authenticate the identity of the server, but SSL encryption is symmetric via a secretly negotiated session key and has nothing to do with the public key in the certificate.

And a server then uses it's private key to decrypt the data.

No.

How does the java client code links to this installed public key to encrypt data while communicating to such server?

Usually via the javax.net.ssl.trustStore property, but again it doesn't use that for encryption, only for authentication.

Who does the SSL encryption here? Is it Java APIs that do it

Yes. It is done by HttpsURLConnection using a javax.net.ssl.SSLSocket.

or do i have to handle encryption in my client code before sending data to server?

No.

As given in one of the above mentioned post ,we can make client accept all certificates.

You can, but it is radically insecure and should never be done that way.

How will the encryption and decryption work in this scenario? How will the client know which public key to use for encryption as we are not installing any server specific key in client's truststore?

See above, you have a misunderstanding here, but when you accept all certificates you have no idea who you're talking to, so any encryption is completely pointless anyway. Don't do this.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • Thanks.I do understand that its not the public key which is used for encryption.What I meant is it will use the public key to encrypt the secret key to be exchanged .If we do not have a public key ,how will the client encrypt the negotiation of a secret key with server? – WillMcavoy Mar 05 '15 at 18:06
  • That's wrong too. The session key is never exchanged at all. It is negotiated independtly by both ends, via a key-agreement protocol. – user207421 Mar 06 '15 at 05:31