Public Key Cryptography
You need first to understand the principle of public key cryptography. Both the server and the client has it's own public key and (secret/private) key.
The public key can be used for two things.
- Encrypt data to reciption.
- Verify received data from sender or other signed data, such as signed certificates.
The private key can also be used for two things.
- Decrypt received data from sender.
- Sign data to receiver or other data such as signed certificates.
When your sending data to a reciption the following steps are followed:
- The sender sign the data with his private key.
- The sender encrypt's data with reciptions public key
- The receiver decrypt's data with his private key.
- The receiver verify senders signature with senders public key.
A certificate is a «digital document» that verify ownership of the public key, the certificate is signed the same way as other data in public key cryptography. And the certificates can signed in by private key that belong to another certificate that's signed by a third certificate, this is called a certificate chain
Let's take a example, the certificate issuer sends a certificate to a webhost. The certificate that belongs to the certificate issuer is signed by a certificate authority private key. The following steps will be completed.
- The certificate authority creates a public key pair with belonging certificate. (Root-certificate)
- The certificate authority sign it's own certificate with his private key. (Self-signed)
- The certificate issuer creates a public key pair with belonging certificate.
- The certificate authority sign certificate issuers certificate with his private key.
- The webhost creates a public key pair with belonging certificate.
- The certificate issuer sign webhosts certificate with his private key.
This is called a certificate chain, if the certificate of the certificate autority is a trusted certificate, then the webhost's certificate is trusted. This chain can be expanded infinity.
Transport layer security
- If there is a intercepting proxy between the web server and the client, mostly the proxy uses its own signed certificates which the client may or may not trust. Then why don't proxy just take the certificate from server and forward it to client so the client will trust it. Also if the private key is only held by the server, then how come an intermediary give its own certificate and decrypt the message?
Because there is a public key that belongs to the certificate send by the server, the client will encrypt data using the public key of the server, and the middle-man can not decrypt the data send by the client since the middle-man don't have the private key of the server.
- The signature hash generated by the private key can be decrypted with a public key. Can't someone decrypt that other then the client and can see the signature?
The signature is not encrypted, so you cannot decrypt it. But you can verify it using the public key of the sender, and everyone who has the public key to the sender can verify the signature.
- Does the client already has the public key with which it starts the encrypted message or do it first ask the server?
Normally the public key and the certificate is exchanged under the handshake of the TLS session. But it's possible to pre generate a certificate and giving the server that certificate before the TLS handshake. For example is this used in OpenSSH server.