On TLS

 Transport Layer Security, like its predecessor Secure Sockets Layer, is a cryptographic protocol that secures a public TCP connection over the Internet. It is used as an extension to secure HTTP, FTP, SMTP, XMPP and others.

The TLS protocol provides:

• Authentication

  • The server is authenticated to the client (and sometimes vice-versa, as well) via trusted third-party certificates (X.509).
  • Public key infrastructure allows the certificate to be cryptographically signed (private key) and verified (public key).

• Privacy

  • A shared ephemeral symmetric cryptographic key is generated by the Diffie-Hellman-Merkle Diffie-Hellman-Merkle (DHM) key exchange algorithm to be used during the session.

• Integrity

  • A message authentication code ensures that none of the bits have been fiddled with in transit by a third-party and prevents undetected data loss.

Let’s look at an example of HTTPS. As for the handshake itself, the description below can serve as a condensed and simplified version of the negotiation between client and server. Note that this has been simplified for clarity and understanding. For example, depending upon the cipher suite selected by the server, the handshake could look greatly different, i.e., the client also providing authentication by sending the server its own signed certificate, among other things.

1. Negotiation phase:

   • Client sends server the highest version of TLS that it supports along with a list of cipher suites (and other bits).
   • Server selects the strongest cipher suite (i.e., a “toolkit” comprised of a key exchange algorithm, a message authentication code (MAC) algorithm, and others) to use from the list sent to it by client.
   • Server sends its certificate along with its public key.
   • Client will use server’s public key to verify the signed certificate and to encrypt the PreMasterSecret that it sends back to server.
   • Client and server then compute the shared secret symmetric key that is used for the rest of the session.

2. Client uses the new shared secret to symmetrically encrypt a Finished message and sends to server, communicating that all its traffic from this point forward will be encrypted. Server decrypts and verifies message, otherwise connection is torn down.

3. Server decrypts using new shared key and encrypts a Finished message to send to client, communicating that all its traffic from this point forward will be encrypted. Client decrypts and verifies message, otherwise connection is torn down.

4. Application phase:

   • The secure channel has been established and encrypted communication commences.

You can see this in action by using curl to fetch a page from a site that has a certificate installed (if the certificate is self-signed, use the --insecure flag with the following command):

    curl -v https://www.theowlsnestfarm.com

    * TLSv1.2 (OUT), TLS header, Certificate Status (22):
    * TLSv1.2 (OUT), TLS handshake, Client hello (1):
    * TLSv1.2 (IN), TLS handshake, Server hello (2):
    * TLSv1.2 (IN), TLS handshake, Certificate (11):
    * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
    * TLSv1.2 (IN), TLS handshake, Server finished (14):
    * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
    * TLSv1.2 (OUT), TLS change cipher, Client hello (1):
    * TLSv1.2 (OUT), TLS handshake, Finished (20):
    * TLSv1.2 (IN), TLS change cipher, Client hello (1):
    * TLSv1.2 (IN), TLS handshake, Finished (20):

One of the interesting points to me is the end of the negotiation phase (Step 1). The emphasis notes where DHM comes into play during the TLS handshake, and this shows how the symmetric key is agreed upon over a public channel in which an eavesdropper cannot determine the shared key even though some bits can be known. I’ll have a future post in which I’ll outline that key exchange algorithm.

TLS uses asymmetric (public key) cryptography for authentication and symmetric cryptography for privacy. The reason for this is that the former is expensive and the latter is very fast. In other words, once the handshake has been negotiated and the connection established, the generated symmetric key is the only crypto that is used for the rest of the session.

Lastly, since DHM establishes an ephemeral shared symmetric key during the handshake that is essentially “thrown away” at the end of the session, TLS also provides for forward secrecy.

from https://www.benjamintoll.com/2018/04/23/on-tls/