2
$\begingroup$

I recently bought an SSL certificate from a website and was able to make it work on my Apache server.

As far as I know, it uses asymmetric keys and the private key is stored on the server while the public key is inside the browser.

My question is, how does the private key work on the browser side? Is it one for everyone, or each time I visit the website, my server sends the visitor a new public key? How is the public key generated every time?

$\endgroup$
1
$\begingroup$

While there are many TLS configurations, I will describe the most common setup.

The public key is fixed on the server side - it is the servers public key. Upon connecting to the server and receiving the public key, the client then validates the key by checking that it has not expired, that it matches the domain name of the server who sent it, and most importantly, that it has been signed by a recognized certificate issuer.

The list of certificate issuers is managed by the browser, and with each software update the list can have entries added and removed. Ultimately, you are trusting your browser vendor to keep the list of well reputed certificate issuers up-to-date.

Once the authenticity of the server certificate has been established, the symmetric encryption will begin under a randomly chosen session key which is discarded after the connection is terminated. This session key is negotiated by the client and the server using the servers ability to decrypt data that you encrypt using the public key embedded in it's certificate.

Using an asymmetric encryption algorithm to establish symmetric session keys in this way is known as hybrid encryption. Asymmetric encryption is used sparingly in practice because it is much slower than symmetric encryption.

$\endgroup$
  • $\begingroup$ Thanks @TruthSerum for taking the time and answering this. So basically whenever someone visits my site lets say www.mysite.com which has SSL installed. first before encrypting the connection, there is an authenticity check and then they decide the encrypt the connection using a symmetric key rather than asymmetric ? I would appreciate if you convert your answer into series of steps stating what happens in chronological order. If it takes too much of your time, I'd understand. Thanks a lot. $\endgroup$ – James Ronaldo Apr 4 '16 at 13:29
  • $\begingroup$ just search for "TLS handshake steps", such as: ibm.com/support/knowledgecenter/SSFKSJ_7.1.0/com.ibm.mq.doc/… but generally - first the certificate is validated, then the keys are derived (there are different key exchange protocols, such as Diffie-Hellman, but here the asymmetric encryption takes place) . Once the keys are computed, the symmetric encryption is used for communication. $\endgroup$ – gusto2 Jul 6 '16 at 13:23
0
$\begingroup$

There is typically no private key on the client side.

At a high level the process goes something along the lines of (this is a simplification, read the protocol specs if you want the fine details)

The client sends the server a "hello" message with info on supported protocols and ciphersuites.

The server chooses a cipersuite and protoocol version and sends the client details of the ciphersuite and sends it's certificate.

The client validates the certificate using the certificate chain to decide whether it is talking to the right server.

The client and server agree a master shared secret for the session and the client validates that the server it is talking to holds the private key for the certificate. Theres a couple of ways this can be done, the simplest is that the client generates the secret, encrypts it using the server's RSA public key and sends it to the server which decrypts it using its private key. The downside of that approach is it doesn't provide "forward secrecy". An alternative approach is to use ephemeral diffe-hellman key exchange (or it's elliptic curve variant) to agree on a secret and use RSA signatures to validate that the key really was agreed with your server (and not agreed with a man in the middle).

Session keys are generated from the master shared secret and encrypted communication begins using a symetric cipher and those sesion keys.

$\endgroup$
  • $\begingroup$ The master secret is being agreed upon, multiple session keys are derived from this secret. $\endgroup$ – Maarten Bodewes Apr 4 '16 at 23:08
  • $\begingroup$ Ok, answer edited. $\endgroup$ – Peter Green Apr 5 '16 at 0:16

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.