4

I have gone through many of the posts including My understanding of how HTTPS works (gmail for example). Everywhere it's mentioning that before creating a https connection, the browser verifies the server's certificate and then uses the server's public key to encrypt data to the server, and server then decrypts using its private key.

But where does this public key come from?

While generating certificates, aren't we generating private key which the server use to decrypt data?

Also, how does the server respond if it has to use the public key for encrypting the reply? How is the browser going to decrypt encrypted reply from server since there is no private key at browser side?

Community
  • 1
kevin
  • 63
  • 1
  • 7

3 Answers3

7

The SSL handshake is not encrypted. The server simply sends its public key in the plain. The client knows it can trust it, because it's signed by a totally trustworthy CA. A certificate is essentially a public key with some associated data such as a domain, signed by a CA.

The client doesn't need to be able to decrypt the PreMasterSecret (from which the session key is derived), because it chose its value and still remembers it.

Take a look at how the SSL handshake works:

  • Negotiation phase:
    • A client sends a ClientHello message ...
    • The server responds with a ServerHello message ...
    • The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the server). This contains the public key
    • The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.
    • The client responds with a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. This PreMasterSecret is encrypted using the public key of the server certificate.
    • The client and server then use the random numbers and ''PreMasterSecret'' to compute a common secret, called the "master secret". All other key data for this connection is derived from this master secret (and the client- and server-generated random values)
  • The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from now on will be encrypted and authenticated
  • Finally, the client sends an authenticated and encrypted Finished message, containing a hash and MAC over the previous handshake messages.
  • The server will attempt to decrypt the client's Finished message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down.
  • Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be authenticated and encrypted
  • The server sends its authenticated and encrypted '''Finished''' message.
  • The client performs the same decryption and verification.

(Based on wikipedia Secure Sockets Layer - Simple TLS handshake)

As you can see, the encryption is only enabled after the negotiation and thus transfer of the public key completed.

CodesInChaos
  • 11,854
  • 2
  • 40
  • 50
  • You could link your word '*totally*' to my question about certification authority security for a nice digression. – lynks Dec 06 '12 at 18:06
3

But from where does this public key come from?

The public key is embedded in the server's certificate.

While generating certificates aren't we generating private key which the server use to decrypt data?

That is already generated before the certificate is made. The keypair is created, then a certificate written, a certificate signing request is sent to a certificate authority, and finally a signed certificate returned to the requestor.

How does the server reply if it has to use public key for encrypting the reply?

The browser uses the server's public key to encrypt a random value for use as a symmetric encryption key. That value is sent to the server. The server replies using a symmetric cipher.

How is the browser going to decrypt the encrypted reply from server since there is no private key at browser side?

Replies are not keyed to a public / private keypair. Microsoft does a decent job of describing the handshake process: http://support.microsoft.com/kb/257591

Jeff Ferland
  • 38,090
  • 9
  • 93
  • 171
1

The server's public key comes from his certificate. The certificate contains the public key, and the server sends it to the client as part of the initial steps of the protocol. The hard part is not knowing the public key, but making sure that this is the right one (that's the whole problematic of certificate validation).

See for instance this answer and then that one.

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949