7

HTTPS connection overview

That shows the mechanism of the connection.

How many keys are being used in this connection? What are they? Who knows them? What is the purpose of each key?

  • 1
    I think you need to rephrase the question. There are many different ways this could be answered depending on what you're asking. Do you want to know how SSL/TLS works or are you actually asking about the specific key-exchange mechanism used in the connection you show? – schroeder Dec 6 '15 at 17:16
  • Yes, but I specifically want to know how many keys and how they are working through this specific connection. – Sh7ne Dec 6 '15 at 17:18
2

There are at least three keys:

  1. X.509 public key: known to all parties who can connect and to the server: used to identify the server and as part of initial key exchange (first half of assymmetric key pair).
  2. X.509 private key: known only to the server: used to prove that the server is entitled to represent itself as the subject of the public key (second half of assymmetric key pair)
  3. session key: known to both the server and the single client of the connection: a symmetric key negotiated via key exchange and replaced based on cipher suite configuration. Used to encrypt data sent over the TLS connection

The session key can be replaced seamlessly during the session in certain configurations. This can be used to provide PFS (perfect forward secrecy) in cipher suites that support it.

There is no inherent bound on the number of session keys that can be used for a single connection.

In some configurations one or more X.509 CA intermediate public keys (chain) are also in the signing chain of the server's public key. These are known to all parties who connect to any server signed by the same chain and to the server. The server must provide these keys during TLS handshake. In all configurations of a CA validated TLS connection the chain will be signed at the root by a root CA which your client software is configured to trust inherently.

If you are including CA certs there are at least four keys and possibly more if intermediate CA certs are used.

  • 1
    Thanks a lot bro! Specific to this connection there should be a key pair for the ECDHE, a key for the AES_128_GCM and a key for the MAC, is that right? – Sh7ne Dec 6 '15 at 18:29
  • @Sh7ne the server's X.509 keypair is used for the ECDHE. The session key would be an AES 128-bit key and GCM would be the cipher block chaining mode (an AEAD mode, which is nice since it provides tampering protection). Not sure about the MAC, I'll have to look into that further. – Alain O'Dea Dec 6 '15 at 18:32
  • 1
    Alain - are you sure that the server's keypair is used when ECDHE is in place? I think that it uses an ephemeral key at this point. See this answer and a summary of the TLS handshake. – Neil Smithline Dec 7 '15 at 2:18
  • 1
    @Neil +Sh7ne ECDHE_ECDSA ServerKeyExchange contains the (public half and parameters of) server's ephemeral ECDH key and is signed (and verified) with server's static and certificated ECDSA key. ClientKeyExchange contains (public half of) client's ephemeral ECDH key. Both ephemeral ECDH keys are combined to produce the premaster secret, which is derived to produce the master secret, which is derived to produce FOUR working keys: one GCM key in each direction and one GCM partial IV or "salt" in each direction. ... – dave_thompson_085 Dec 7 '15 at 3:46
  • 1
    ... This is all described in detail in rfcs 5246 plus 4492 and 5288 (referenced from 5289), which is the place to look if you want a complete and correct answer. Note the Wikipedia "Summary" is labelled "basic" and links only to 5246 and apparently does not cover EC which is in 4492 (plus updates in 5246 A.7). – dave_thompson_085 Dec 7 '15 at 3:46
2

All together there should be sixteen (16) keys that come in to play:

(a) GeoTrust Global CA signing key, used to self-sign GeoTrust’s certificate, and to sign Google Internet Authority G2’s certificate. Only Geo trust knows it.

(b) GeoTrust Global CA verification key, used to verify the signatures on GeoTrust’s certificate, and Google Internet Authority G2’s certificate. Everyone knows it.

(c) Google Internet Authority G2’s signing key, used to sign Google.ca’s certificate. Only Google Internet Authority G2 knows it.

(d) Google Internet Authority G2’s verification key, used to verify signature on google.ca’s certificate. Everyone knows it.

(e) Google.ca’s signing key, used to sign Google.ca’s ephemeral elliptic-curve Diffie-Hellman (ECDHE) public key. Only google.ca knows it.

(f) Google.ca’s verification key, used to verify the signature on google.ca’s ECDHE public key. Everyone knows it.

(g) Google.ca’s ECDHE public key, sent to client for key agreement. Everyone knows it.

(h) Google.ca’s ECDHE private key, used to generate the corresponding public key, and to apply to client’s public key to form shared secret. Only Google.ca knows it.

(i) Client’s ECDHE public key, sent to google.ca for key agreement. Everyone knows it.

(j) Client’s ECDHE private key, used to generate the corresponding public key, and to apply to google.ca’s public key to form shared secret. Only client knows it.

(k) Shared secret. It is the result of ECDHE key exchange, also called the pre-master secret. Only client and server know it.

(l) Master secret. Derived from pre-master secret and client/server random values, and used to derive the following symmetric key. Only client and server know it.

(m) Client-write symmetric encryption key. Only client and server know it.

(n) Server-write symmetric encryption key. Only client and server know it.

(o) Client-write MAC key. Only client and server know it.

(p) Server-write MAC key. Only client and server know it.

  • GCM (and CCM also) does not use MAC secrets but does use "IVs" (actually partial nonces). – dave_thompson_085 Dec 13 '15 at 3:37
  • @dave_thompson_085 you sure? – Sh7ne Dec 13 '15 at 4:46
  • rfc5246 6.2.3.3 "The [AEAD] key is either the client_write_key or the server_write_key. No MAC key is used." "In many cases [including GCM and CCM per 5288 and 6655] the implicit part [of the record nonces are] client_write_iv and server_write_iv ...." – dave_thompson_085 Dec 15 '15 at 4:38
0

See The First Few Milliseconds of an HTTPS Connection, Generating Lots of Keys section.

You have:

  • cient_write_MAC_secret[SecurityParameters.hash_size]
  • server_write_MAC_secret[SecurityParameters.hash_size]
  • client_write_key[SecurityParameters.key_material_length]
  • server_write_key[SecurityParameters.key_material_length]
  • client_write_IV[SecurityParameters.IV_size]
  • server_write_IV[SecurityParameters.IV_size]

Although whether you'd call the IVs keys or not is another matter (and also they may not be used, e.g. in AES stream cipher mode).

Also you will have the private and public keys in the certificate.

Both parties know all the above keys, with the exception of the private key which only the server knows. MACs are used to authenticate each message, and write_keys are used to encrypt them. Note that the client and server use different keys to encrypt messages.

The public and private key pair are used to authenticate the server - that is, the client knows that they are talking to the correct server and that the connection has not been intercepted. This is either because the client encrypts a secret that can only be decrypted by the server with its knowledge of the private key, or that the server sends random numbers (in the case of Diffie-Hellman) that are signed by the private key. The client can use the public key to verify the signature.

  • GCM does not use MAC secrets. It and CCM are the only "AES stream" modes in SSL/TLS (at least to date) and both do use KDFed IVs which contribute part (but only part) of the AEAD nonces; these are identified as key material but as you say it's arguable if they are actually keys.l – dave_thompson_085 Dec 13 '15 at 3:37

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.