So from what I understand it generally works like this:
- Client connects to the server
For HTTPS yes. For other applications it varies; some make a new connection and some reuse an existing connection.
- Client tells server about their supported protocol (e.g. TLS 1.2) AND the cipher suite (e.g. ECDHE-RSA-AES128-GCM-SHA256)
Ciphersuites plural, and quite a few other things in extensions, both shown in the article you link. (Which highlights SNI as relevant to the IIS/http.sys logic being described.)
- Server answers and agrees on a protocol and cipher suite they both support (e.g. TLS 1.2 & ECDHE-RSA-AES128-GCM-SHA256), as well as the servers certificate (also containing their public key)
The certificate contains the static (long-term) public key, and as ISMSDEV said is accompanied by any intermediate aka chain certs, and optionally the root cert. The article doesn't clearly state, but does show in the network trace, that the certificate(s) are actually a separate message but possibly in the same SSL/TLS record and almost always in the same TCP frames. For ephemeral keyexchange, as in the ciphersuite you specified but not the one in the article, the server's ephemeral key (with parameter(s) and signature much as ISMSDEV said) is in a separate message ServerKeyExchange; then optionally another message to 'Request' a client certificate, again not clearly stated and this time not shown; then a ServerHelloDone message, not described at all but shown.
--- now from here on they communicate based on the chosen protocol and the role of the cipher suite becomes important ---
The protocol version/format and key-exchange have already affected the server messages above. The symmetric cipher and possibly hash don't have effect yet.
- The client verifies the server's certificate against known certificate authorities and extracts the server's public key for the key exchange
Verifies the certificate chain, extracts the longterm (certified) key and also extracts and verifies the ephemeral key if used, which it is in the ciphersuite you specified.
- Now the cipher suite's key exchange kicks in (in this case ECDHE-RSA), which uses the server's public key - the result is the pre-master secret (as depicted in the diagram below)
Key-exchange has already started, with the server messages above; it is now completed using the client's key. The diagram you copy shows an arrow from client to server with (encrypted) pre-master secret because it is for a ciphersuite using RSA key-exchange, but you specified a ciphersuite using ECDHE-RSA key-exchange and for that the client's ephemeral publickey is sent (in clear) instead and the ECDH algorithm is used, independently at both peers, to derive the pre-master secret.
In addition if client certificate (aka client authentication) was requested, the client may send its own cert chain and its signature on a transcript through the client's key exchange message, (both) as separate messages, as described in the article but not shown.
- With the pre-master secret, both the cipher and the hashing algorithm are then used (in this case AES128-GCM and SHA256) for the message encryption and digests.
- The key exchange is repeated, encrypted with the cipher, using the pre-shared secret and verified with the hashing algorithm. The result is the master secret
Nothing is repeated, and nothing directly uses the pre-master secret. Instead the pre-master secret is used with the 'random' (nonce) values from the Hello messages in an algorithm called the PRF (Pseudo-Random Function) to derive the master secret, and then the master secret is similarly used to derive several session keys. As the article says:
[the server] performs a series of steps (which the client also performs, starting from the same pre-master secret) to generate the master secret.
(bullet) Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity [....]
Note the plural in 'session keys'. For some ciphersuites in TLS1.2, including the one you specified, the hash in the ciphersuite affects the PRF. For other ciphersuites, and all lower protocol versions, it does not. See What's the hash for in ECDHE-RSA-AES-GCM-SHA? .
- The master secret is used with the cipher and hashing algorithm, to encrypt any further communication.
Each endpoint sends a message ChangeCipherSpec to 'activate' the ciphersuite and then a message Finished, which is the first encrypted (and MACed) message. As the article says:
The CLIENT & the SERVER send each other a message informing that future messages from them will be encrypted with the session key. It then sends a separate (encrypted) message indicating that its portion of the handshake is finished.
Nothing directly uses the master key. Symmetric (data) encryption uses two of the session keys (one for each direction). For ciphersuites that use HMAC for integrity (as in the article), it uses the hash algorithm from the ciphersuite (and two more session keys), but you specified a ciphersuite which uses GCM mode, which as ISMSDEV said provides its own authentication (not using any hash).