SSL encryption process and its security

Question

I know the basics of SSL encryption and how certificates work, but there are some points that are not clear to me regarding the SSL security:

1. 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?

2. 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?

3. Does the client already has the public key with which it starts the encrypted message or do it first ask the server?

Answer 1

1. 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?

If the intercepting proxy uses self-signed (or signed by it's own CA) certificates generated on the fly, the certificate passed to the client won't be trusted, as it has no valid certificate chain. If the certificates or the used CA is trusted by the client (which is often the case in internal networks), all traffic can be sniffed without suspicion by the gullible user. However, you can detect the interception by looking at the certificate (chain) in your software.

If the proxy does not use its own certificate but the certificate of the server, it can't decrypt the traffic. The public key in the certificate always corresponds to one specific private key, which is not known for others.

The server certificate contains a digital signature of the CA (mostly an intermediate certificate), which is a signed hash value. The signature is generate with their private key and can be verified with the public key using the next certificate in the key chain. This can be repeated several time, until a certificate is given, which has no parent and is trusted by the client (Root-certificate)

2. 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 does not contain any confidential information. Usually the signature is based on a hash value of a file, message or (parts of) a certificate. Everyone with the public key can verify the signature and compare the hash values. If they do match, the signature is valid, otherwise not.

See also What is the actual value of a certificate fingerprint?

3. Does the client already has the public key with which it starts the encrypted message or do it first ask the server?

Unless the client uses certificate pinning, it does not have informations about the servers certificate and public key. The server sends the certificate at the beginning of a TLS session.

Answer 2

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:

1. The sender sign the data with his private key.
2. The sender encrypt's data with reciptions public key
3. The receiver decrypt's data with his private key.
4. The receiver verify senders signature with senders public key.

Certificate chain

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.

1. The certificate authority creates a public key pair with belonging certificate. (Root-certificate)
2. The certificate authority sign it's own certificate with his private key. (Self-signed)
3. The certificate issuer creates a public key pair with belonging certificate.
4. The certificate authority sign certificate issuers certificate with his private key.
5. The webhost creates a public key pair with belonging certificate.
6. 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

1. 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.

2. 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.

3. 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.

Answer 3

The intermediary would need to "spoof" the server's cert by creating a cert with the same hostname but which has a keypair controlled by the intermediary.

This is because if the intermediary just passes the actual server's cert to the client then the client and server will establish a secure exchange of keys and an encrypted channel that the intermediary will not be able to eavesdrop on. If you think about this there would be no value to SSL at all if this wasn't the case as the internet is a decentralized network and there is always multiple intermediaries between the client and server.

So in an https intercepting proxy, the intermediary will take the details of the server's cert and create a new cert with the same hostname but which has keys the intermediary controls so the intermediary can decrypt both communication between itself and the client and itself and server. In most cases this alone will not be sufficient however. As a security measure, browsers will warn on any self signed certs or certs signed by roots they don't trust. In order to correctly impersonate the real server to a client the intermediary's root cert would need to be installed in the client's trusted root store.

Answer 4

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?

If the proxy took the certificate from the server then it won't be able to decrypt the premaster secret send by the client, as this is encrypted with the public key from the server.

If an intermediary gives its own certificate, the client will encrypt the premaster secret with the public key of the proxy, not the server.

You can think of an intercepting proxy being both a server and a client. So instead of

Client --> Server

It is

Client --> Proxy Server --> Proxy Client -- > Server

so there will be two separate connections, and two separate SSL/TLS tunnels.

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?

Not sure what you mean with this. It is not decryption or encryption, it is a signature. A client can verify that something was signed by a private key with the corresponding public key, but nothing else can sign anything without the private key.

Does the client already has the public key with which it starts the encrypted message or do it first ask the server?

The server sends the certificate chain in its server hello message. The certificate leaf contains the public key. The client already has root certificates so it knows what to trust (any chain that leads to a trusted root).

Check out The First Few Milliseconds of an HTTPS Connection for a good primer guide.