0

Let's said we're running asymmetric encryption on a server with DV SSL encryption. With this condition set, how do we send the users' public key and private key generate in server to client in order they can decrypt and encrypt their message in their end securely?

I have an idea that is make a POST protocol which can prevent normal user visit using GET to retrieve. Then, how do we send it securely? We shouldn't send the key pair in plain text right? But how can we send it encrypted while user don't know the decryption key? And if we send them the key the same issue occurs again.

Edit:

As @Steffen Ullrich mentioned, my private and public key meant the key pair use for encrypting message to send to other user (quite like the Bob and Alice, it's the key pair that Bob use to encrypt/decrypt message to/from Alice and vice versa), the only SSL related word in DV SSL which I said it because the secure level, since most security expert said you should use a EV SSL to provide a more secure environment but I only have DV.

Andrew.Wolphoe
  • 223
  • 1
  • 8
  • It is unclear what you are asking. Which public key you are talking about? The one from the servers certificate? In this case you might miss a basic understanding of how SSL/TLS works and [How does SSL/TLS work?](https://security.stackexchange.com/questions/20803/how-does-ssl-tls-work) might help you. – Steffen Ullrich Oct 17 '17 at 10:37
  • @SteffenUllrich I update the question, all the keys said in the question are for message (document) encryption, not for SSL, and this question is asking transferring encryption keys securely not asking SSL related question, but thanks for pointing out the unclear part. – Andrew.Wolphoe Oct 17 '17 at 10:43
  • Why are you trying to send a private key to the client? There is no reason the server should ever be handling a user's private key, rather the client should generate the private key and then send only the public key to the server. It's very rare that transmitting a private key is a good plan. – AJ Henderson Oct 19 '17 at 15:56
  • It is also unclear why your client needs their own private key. Asymmetric cryptography is not used for SSL connections after being established. You only need a private key for a client if you want to use cryptographic authentication of the end user in the future. The SSL certificate on the server allows for secure establishment of a symmetric session key which is used for the connection and then discarded. – AJ Henderson Oct 19 '17 at 15:58
  • @AJHenderson So you meant there is no need to encrypt anything if the connection is established in HTTPS? If yes why someone tells me facebook's messenger also encrypts users' message? – Andrew.Wolphoe Oct 19 '17 at 16:11
  • @Munucial - HTTPS using a modern version of TLS will provide plenty of security for communication over the network. The reason some clients do client side encryption beyond that is to protect communications from the server. Some secure messaging systems use a server as a relay between two communicating parties. HTTPS is only point to point, it secures one link, but the server knows what is going on. The messaging client can encrypt it so that the message is not accessible to the server, but only to the final receiving client. – AJ Henderson Oct 19 '17 at 16:26
  • It seems like you have a lot of misconceptions on the purpose and use cases for encryption. You may want to consider hopping in [chat](https://chat.stackexchange.com/rooms/151/the-dmz) for something more discussion oriented to figure out more about what you are trying to do and what is relevant. – AJ Henderson Oct 19 '17 at 16:28

1 Answers1

2

If I understand your question correctly you attempt to make the encryption stronger by adding another encryption layer on top of SSL. And you want to do this since you believe that EV certificates provide a stronger encryption than DV certificates but you cannot get an EV certificate.

If I understood you correctly then you are having a wrong understanding of SSL/TLS: the strength of the encryption does not depend on DV vs. EV certificates. The only difference between these is that there are fewer issuers for EV certificates and that these issuers check the identity more thoroughly of the party applying for an EV certificate. This means, there are no real technical differences which affect the encryption strength, but mainly organizational ones. One difference is though that browser tend do enforce revocation checks on RV certificates but often not for DV certificates.

But due to this organizational differences the chance is higher that somebody gets a DV certificate for your domain, for example by compromising your site, DNS or email for a short time. Thus you might be inclined to increase the trust in your peer by adding another protection layer. Only, the way you envision to exchange a key pair will not work since this would use the connection you already distrust. Instead such information would need to be provided either out of band (like send your certificates key in a really secure and trustable way to the peer) or by doing trust on first use (TOFU), i.e. assume that the first contact will be not compromised and exchange for example the expected key fingerprint for all future connections using HPKP.

Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
  • So do you meant transferring key pair plain text through DV is secure? If not what's other method to keep it secure? Or, there is always vulnerable in Internet no matter how you defend it? – Andrew.Wolphoe Oct 17 '17 at 10:55
  • @Munucial: the encryption is already provided by SSL, no matter if using DV or EV certificates. No need to add additional encryption on top of it. – Steffen Ullrich Oct 17 '17 at 11:05
  • Then if my CA is Let's Encrypt, do they have any warranty of data safety or something like that? Also if the key has leak and the information got decrypted should we take our responsibility? Or since Let's encrypt is a free SSL provider they don't have any warranty about data leaking? – Andrew.Wolphoe Oct 17 '17 at 12:48
  • 2
    None of this has anything to do with DV / EV. All EV does is show the CA verified who owns the domain. With DV they simply verified the person they handed the certificate to controls the domain (not who that person is). If a user has opened a connection to you after seeing a DV certificate they are confirming they are happy with the validation DV provides. The encryption over the connection is identical whether DV or EV. – Hector Oct 17 '17 at 12:52
  • Further most CA's do not store your private key. Once they give you the key pair only you can be responsible for leaking it (and hence encrypted information being decrypted by a third party). The CA's responsibility is to only give out keys to verified parties and to verify them exactly as stated. – Hector Oct 17 '17 at 12:55
  • 1
    @Munucial: I recommend that you get a better understanding of how SSL/TLS works in the first place since you seem to have some serious misconceptions. See [How does SSL/TLS work?](https://security.stackexchange.com/questions/20803/how-does-ssl-tls-work). – Steffen Ullrich Oct 17 '17 at 14:32