TLS handshake protocol

After watching the lecture about SSL and TLS (lecture 41), I can’t get my head around how the TLS handshake protocol is private between the sender and receiver? Because if I understand it correctly this protocol is to ensure that both parties have a session key in order to encrypt and decrypt info from each other, to prevent a middle man to know what the info is in case it get hold of it.

Why is it not possible e.g. a sender sends a request to a server, and that a middle man intercept that request? And pretending to be that server. And giving its own public key and all the other things needed.

Or is it because of the authentication? Because a company gets it certificate from a certified authority? And your browser checks wether its legit or not? But is it not possible to make your own certificate? Or is that maybe the reason why you get an exclamation mark after https://? Telling you, yes your communication is encrypted, but the server is not trustworthy.

In advance I would like to thank you, for taking your time in answering my question.

The certificate validates that the public key is that of the server. i.e. authenticates the server. This is done through a chain of trust to a root cert in your browser. We cover this is a later lecture. If I give my own certificate in an attempt to authenticate as a fake server I would need to be a certificate authority to generate a valid certificate. I cover the weaknesses later in how you might do this. SSL with certificate authentication is far from perfect. But this is the authentication used in HTTPs.

The connect is private/confidential because a symmetric algorithm such as AES is used to encrypt the data transmitted

The keys for this symmetric encryption need to be exchanged or agreed during the handshake.

Among the methods available for key exchange/agreement are: public and private keys generated with RSA (denoted TLS_RSA in the TLS handshake protocol), Diffie-Hellman (TLS_DH), ephemeral Diffie-Hellman (TLS_DHE), Elliptic Curve Diffie-Hellman (TLS_ECDH), ephemeral Elliptic Curve Diffie-Hellman (TLS_ECDHE), anonymous Diffie-Hellman (TLS_DH_anon), pre-shared key (TLS_PSK) and Secure Remote Password (TLS_SRP).

These methods use different mathematics to enable the exchange of keys in a way that prevents an eavesdropper from determining the key.

• Rivest-Shamir-Adleman (RSA) - Security of this algorithm comes from the difficulty of factoring large numbers into their original prime numbers.
• Elliptic curve cryptosystem (ECC) - Security of this algorithm computes discrete logarithms of elliptic curves,
• Diffie-Hellman Security of this algorithm calculating discrete logarithms in a finite field

Example of one method

From wiki

Elliptic curve Diffie–Hellman (ECDH) is an anonymous key agreement protocol that allows two parties, each having an elliptic curve public–private key pair, to establish a shared secret over an insecure channel. [1][2][3] his shared secret may be directly used as a key, or to derive another key which can then be used to encrypt subsequent communications using a symmetric key cipher. It is a variant of the Diffie–Hellman protocol using elliptic curve cryptography.

Key establishment protocol

The following example will illustrate how a key establishment is made. Suppose Alice wants to establish a shared key with Bob, but the only channel available for them may be eavesdropped by a third party. Initially, the domain parameters (that is ) in the prime case or in the binary case) must be agreed upon. Also, each party must have a key pair suitable for elliptic curve cryptography, consisting of a private key (a randomly selected integer in the interval ) and a public key (where , that is, the result of adding together times). Let Alice’s key pair be and Bob’s key pair be . Each party must know the other party’s public key prior to execution of the protocol.

Alice computes . Bob computes . The shared secret is (the x coordinate of the point). Most standardized protocols based on ECDH derived a symmetric key from using some hash-based key derivation function.

The shared secret calculated by both parties is equal, because .

The only information about her private key that Alice initially exposes is her public key. So, no party other than Alice can determine Alice’s private key, unless that party can solve the elliptic curve discrete logarithm problem. Bob’s private key is similarly secure. No party other than Alice or Bob can compute the shared secret, unless that party can solve the elliptic curve Diffie–Hellman problem.

The public keys are either static (and trusted, say via a certificate) or ephemeral (shortcut ECDHE). Ephemeral keys re temporary and not necessarily authenticated, so if authentication is desired, authenticity assurances must be obtained by other means. Authentication is necessary to avoid man-in-the-middle attacks. f one of Alice or Bob’s public key is static then man-in-the-middle attacks are thwarted. Static public keys provide neither forward secrecy or key-compromise impersonation resilience, among other advanced security properties. Holders of static private keys should validate the other public key, and should apply a secure key derivation function to the raw Diffie–Hellman shared secret to avoid leaking information about the static private key. For schemes with other security properties, see MQV.

While the shared secret may be used directly as a key, it is often desirable to hash the secret to remove weak bits due to the Diffie–Hellman exchange.[4]