Below is the explanation of TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 -
Asymmetric Cryptography
There are two different parts to creating a TLS session. There is the asymmetric cryptography portion which is an exchange of public keys between two points. Which is what you saw in your Alice and Bob example. This only allows the exchange of asymmetric keys for asymmetric encryption/decryption. This is the ECDHE portion. The RSA portion describes the signing algorithm used to authenticate the key exchange. This is also performed with asymmetric cryptography. The idea is that you sign the data with your private key, and then the other party can verify with your public key.
Symmetric Cryptography
You encrypt symmetric encryption/decryption keys with your asymmetric key. Asymmetric encryption is very slow (relatively speaking). You don't want to have to encrypt with it constantly. This is what Symmetric Cryptography is for. So now we're at AES_128_GCM.
AES is the symmetric algorithm
128 refers to key size in bits
GCM is the mode of operation
So what exactly does our asymmetric key encrypt? Well we want to essentially encrypt the symmetric key (in this case 128 bits, 16 bytes). If anyone knew the symmetric key then they could decrypt all of our data. For TLS the symmetric key isn't sent directly. Something called the pre-master secret is encrypted and sent across. From this value the client and server can generate all the keys and IVs needed for encryption and data integrity. Detailed look at the TLS Key Exchange
Data Integrity
Data integrity is needed throughout this process, as well as with the encrypted channel. As you saw when looking up GCM, the encryption mode of operation itself provides for the integrity of the data being encrypted. However, the public key handshake itself must also be confirmed. If someone in the middle changed data while being transmitted then how could we know nothing was tampered with? This is the instance where the negotiated hash function is used, SHA256. Every piece of the handshake is hashed together, and the final hash is transmitted along with the encrypted pre-master secret. The other side verifies this hash to ensure all data that was meant to be sent was received.
SHA256, as mentioned by another poster, is also used for the Pseudo-Random Function (PRF). This is what expands the pre-master secret sent between the two parties into the session keys we need for encryption.
For other modes of operation, each message would be hashed with this integrity algorithm as well. When the data is decrypted the hash is verified before using the plaintext.
Here is a great explanation for how these derivations happen for different TLS versions.
Put all these pieces together and you have yourself a secure mode of communication!
You can list all possible ciphers that OpenSSL supports with openssl ciphers. You can go further and print the details of any of these cipher suites with the -V
For example:
$ openssl ciphers -V ECDHE-RSA-AES256-GCM-SHA384
0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
0xC0,0x30 represents the two byte identifier for the cipher suite
Kx=ECDH represents the key exchange algorithm
Au=RSA represents the authentication algorithm
Enc=AESGCM(256) represents the symmetric encryption algorithm
Mac=AEAD represents the message authentication check algorithm used
