17

I have a web server built up relying on HTTPS. So, my server maintains its private key and publish a public key that any clients can use to encrypt their request. Since my server is the only one who has the private key to decrypt any message encryped using server's public key, any request sent this way can be considered secure.

However my question is at the response part. When the server sends the response back to the client, whose public key will the server use to encrypt the response message?

I assume the server will use client's public key to encrypt the response (by default? or upon configuration?). If so, does the server knows the client's public key from the request it sends to the server, or somehow else?

Update: If I understand it incorrectly, then during future communications how each party knows how to decrypt the message the other one sends? Is some key shared or somehow?

Thanks!

Bruce
  • 1,608
  • 2
  • 17
  • 29

3 Answers3

21

Public keys are not directly used to encrypt any of the underlying HTTP traffic on an HTTPS connection; neither the HTTP request nor the HTTP response are encrypted this way. Rather, during the initial SSL handshake, a session specific symmetric key is negotiated between the client and the server, and it's the symmetric key that is then used to encrypt all traffic on the HTTP connection in both directions.

The specific mechanism by which the symmetric key is negotiated depends on the specific cipher suite that is negotiated between client and server. This negotiation always involves the server's public key and a value sent by the client; it may also involve items like a client public key or separate connection specific public keys from the server and client.

Additional detail can be found in RFC 5246 starting here:

https://www.rfc-editor.org/rfc/rfc5246#section-7.3

Community
  • 1
  • 1
Warren Dew
  • 8,790
  • 3
  • 30
  • 44
13

None.

Public and private key are used to negotiate a symmetric encryption key, that will be used during that session. Asymmetric encryption uses two keys (private and public), symmetric encryption uses only one.

Your server sends its public key to a client, the client validates that key signature (check the CA and all that) then use it to encrypt a randomly selected key that will be used as symmetric encryption key, and send it to the server. Because only the private key can decrypt that message, the message is secure, only the server can decrypt it. Then the server accepts that key selected by the client, and they start to transmit data using symmetric encryption.

Why all this? asymmetric encryption is quite computionally expensive, so it is just used to ensure that client and server can negotiate a secure symmetric key without sending it in plain text. Symmetric encryption is cheap.

Symmetric encryption is also safe, the problem is that both parts must know the key before start, and that is a big issue. By using asymmetric encryption for negotiating the key, this problem is solved.

UPDATE

Well, it seems that @EJP does not agree with my answer, so I tried to find some more documentation that explain the thing in an easy way.

http://www.techradar.com/news/software/how-ssl-and-tls-works-1047412

SSL explained

When you visit a bank's website, the bank's server will automatically redirect you to its secure site using the HTTPS protocol before you can log in. This results in your browser and the bank's site negotiating a secure channel using SSL.

This negotiation goes a little like this (note that I've simplified it greatly). The browser sends a message stating what the latest version of SSL it can support and a list of symmetric algorithms it can use. The web server sends back a message with the version of SSL and the algorithm that will be used.

It sends its certificate as well. The client verifies the certificate using the known certificates that came with the browser; in other words, it checks that it has been signed by a trusted CA and that it hasn't expired.

If the certificate is valid, the browser generates a one-time key for the session, encrypts it with the server's public key (it's part of the certificate), and sends it to the server. The server decrypts the key, then uses that key together with the agreed symmetric algorithm for the rest of the session.

I may be confused.

vtortola
  • 34,709
  • 29
  • 161
  • 263
  • Thanks, vtortola. It makes a lot of sense. So during asymmetric encryption phase when client and server are negotiating the key used for symmetric encryption, it is actually the client who choose which key agreed for both parties to use for all future interactions in the same session. If I understand correctly, the symmetric encryption is secure also in the sense that different clients (therefore different sessions) share different symmetric encryption keys with the server, so each client keeps its own secret talk with the server. Is that right? – Bruce Apr 27 '14 at 03:23
  • @Bruce None of this answer is correct except for the first word. The server key and certificate are used to *authenticate* the server, and the peers then negotiate a session key independently via shared secrets. The session key is never transmitted at all. – user207421 Apr 27 '14 at 03:32
  • 1
    You are confused, and so is the author of that shocking article. This is a fairly common misconception, but it's still a misconception. The RFC is the only normative document about SSL, and it specifies the process I described. – user207421 Apr 27 '14 at 19:40
  • Do you have something more digestive than a RFC? If it is a misconception, it is true it is a common one. – vtortola Apr 27 '14 at 19:52
  • I don't need anything 'more digestive than an RFC'. It's all there in black and white. Anyone who wishes to disagree is welcome to produce some counter-evidence, but it has to be from an equally authoritative source, and there isn't one. You can't quote magazine articles at me when I'm citing the RFC. – user207421 Apr 27 '14 at 21:02
  • 1
    @EJP Citing RFC is definitely good enough, but it is also too hard for people around to read through or understand it. I saw your answer here as your version of understanding it. Without denying its correctness there are still some vague spots, like "several ways", "more steps", etc. I did not yet get a clear picture on this, so we are not asking for an equally authoritative translation, but just need an easier-to-understand description of the process. Do you have one?Or a post somewhere with the same understanding of yours - if it's correct there should be one. I would love to read it. Thanks – Bruce Apr 27 '14 at 22:19
  • @Bruce If it's too hard for you to read through, it's too hard to explain here. The question you asked was 'whose public key?' I've answered that. You didn't ask for a précis of the RFC, and I'm not about to give you one. There are good books on the subject, for example Eric Rescoria's. The truth is that you don't really need to know. – user207421 Apr 27 '14 at 22:27
  • 1
    @EJP Both of you answered "whose public key". Now I see I understand it incorrectly. However for the same answer your explanations are different. vtortola claims that during asymmetric phase the symmetric encryption key is negotiated and shared, whereas you said it is not transmitted at all. If yours is right then I really need to know how the decryption can happen without server knowing that key. With all due respect, at stackoverflow one asks "is it true or false..?", the adopted answer among all is not likely to be "I tell you it's true, but you won't know why coz that's your own problem.." – Bruce Apr 27 '14 at 22:43
  • vtortola, @EJP and you may be right on different parts. I checked Symantec's (symantec.com/page.jsp?id=how-ssl-works) and Microsoft's (support.microsoft.com/kb/257591) interpretation. I may need to get a little more information later, but EJP is right in the sense that the pre master secret is shared, but that's used to *generate* session keys for each side, whereas that session key is not transmitted. – Bruce Apr 27 '14 at 23:03
  • right, probably what I said is wrong, that is why I was asking for links. I will give those links a read later. Thanks! – vtortola Apr 27 '14 at 23:47
  • This answer is not technically exact, but for general understanding, it's a reasonable approximation of the case where the client sends a premaster secret: the client doesn't actually encrypt the symmetric key, but it encrypts a random value which the server can decrypt and use to generate the symmetric key. Note that whether a premaster secret is used depends on what exact symmetric cipher is negotiated between client and server. @Bruce I can provide an answer with more detail if you want. – Warren Dew Apr 28 '14 at 05:44
  • @Bruce There is nothing in either the Symantec link or the Microsoft link that contradicts what I have said or that supports vtortola's version. – user207421 Apr 28 '14 at 10:14
  • @WarrenDew This answer is technically wrong. Period. – user207421 Apr 28 '14 at 10:14
  • The Microsoft link states in point 4 that the client generates a pre-master key, encrypt it using the server's public key, and send it to the server. Then in points 7 and 6 says that they both generate the master key from the pre-master key following the same steps, and then generate the symmetric session keys. Is that right? Also, how are the last two paragraphs of my response also wrong? – vtortola Apr 28 '14 at 11:06
  • I am not pursuing to be right, neither concerned about being wrong. I am just trying to find out how wrong or right I am. – vtortola Apr 29 '14 at 10:24
  • You've been told exactly that, in excruciating detail. – user207421 Oct 26 '17 at 10:16
  • Confused on public/private key? This link explains in layman terms: https://medium.com/@vrypan/explaining-public-key-cryptography-to-non-geeks-f0994b3c2d5 – KrishPrabakar Jul 15 '20 at 15:56
  • @KrishPrabakar Your link is irrelevant. Public-key crytography is only used during the SSL handshake. Not what the OP is asking about. – user207421 Oct 17 '20 at 02:39
1

My server maintains its private key and publish a public key

Yes.

that any clients can use to encrypt their request.

No.

Since my server is the only one who has the private key to decrypt any message encryped using server's public key, any request sent this way can be considered secure.

That's not how it works.

However my question is at the response part. When the server sends the response back to the client, whose public key will the server use to encrypt the response message?

Neither.

I assume the server will use client's public key to encrypt the response (by default? or upon configuration?).

No. See below. In most SSL connections the server doesn't even know the client's public key, if indeed the client even has one. This only occurs in so-called 'mutual' SSL, where both peers authenticate to each other.

If so, does the server knows the client's public key from the request it sends to the server, or somehow else?

It only knows the public key if the client sends its certificate, which only happens if the server is configured to request it, which it usually isn't.

HTTPS runs over SSL, which uses a symmetric session key negotiated independently by both peers. It is never transmitted. The server's keypair is only used to provide a digital signature over its certificate, which the client can verify, which proves that that server owns that certificate. From there on it is all symmetric negotiation and encryption.

Authority: RFC 2246 and successors.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • Hi EJP, many thanks for this answer, but I am having a hard time understand this now. Say my client is invoking my service via HTTPS, and, if my server is running over a self-signed certificate, then the client side has to put my public key into trust store to be able to interact with my service. It seems that future requests/responses sent from/to this client is via SSL layer using *symmetric* session key. How does this key negotiated by both parties without transmitting information beforehand? – Bruce Apr 27 '14 at 04:28
  • No. Your client has to put your server *certificate* into its truststore. There are several ways of negotiating a secret session key. It starts with a 'pre-master secret' conveyed by one of the parties but there are several more steps. See the RFC for details. – user207421 Apr 27 '14 at 08:36
  • 1
    @downvoter Don't kid yourself. You're arguing with RFC 2246 here. – user207421 Jul 06 '16 at 20:50