The difference is that
tls_aes_128_gcm_sha256 is TLS 1.3 and
tls_ecdhe_rsa_with_aes_128_gcm_sha256 is used for the older TLS 1.2. The first ciphersuite doesn't specify the key agreement algorithm and the authentication mechanism. Those are likely used, but they are specified / configured elsewhere in the TLS handshake.
TLS 1.3 is basically TLS-done-right; the two protocols aren't compatible, even if the last part of the ciphersuite matches. It can however use the same key agreement and authentication mechanisms (and thus the same server certificate and key).
To quote OpenSSL:
SSL_CTX_set_ciphersuites() is used to configure the available TLSv1.3 ciphersuites for ctx. This is a simple colon (":") separated list of TLSv1.3 ciphersuite names in order of perference. Valid TLSv1.3 ciphersuite names are:
OK, so we're talking TLS 1.3 here, let's look there:
Although TLS 1.3 uses the same cipher suite space as previous
versions of TLS, TLS 1.3 cipher suites are defined differently, only
specifying the symmetric ciphers, and cannot be used for TLS 1.2.
Similarly, cipher suites for TLS 1.2 and lower cannot be used with
So we have two ciphersuites that are largely identical to the message encryption / authentication used. However, one is for TLS 1.2 and also specifies the key agreement and the other is specific to TLS 1.3 and only specifies the message encryption / authentication.
For TLS 1.3 the reason why the other components are not specified is that they are negotiated during the handshake. This makes TLS 1.3 more flexible as it doesn't seen to specify all possible combinations in the cipher suite. However, you should remind yourself that the ciphersuite is far from the only configuration parameter.
From TLS 1.3, section 4.1.1, Cryptographic Negotiation:
In TLS, the cryptographic negotiation proceeds by the client offering
the following four sets of options in its ClientHello:
A list of cipher suites which indicates the AEAD algorithm/HKDF
hash pairs which the client supports.
A "supported_groups" (Section 4.2.7) extension which indicates the
(EC)DHE groups which the client supports and a "key_share"
(Section 4.2.8) extension which contains (EC)DHE shares for some
or all of these groups.
A "signature_algorithms" (Section 4.2.3) extension which indicates
the signature algorithms which the client can accept. A
"signature_algorithms_cert" extension (Section 4.2.3) may also be
added to indicate certificate-specific signature algorithms.
so basically the ECDHE option is now in
supported_groups (DH is required for TLS 1.3) and RSA is in
signature_algorithms, if present.
Short explanation of the terms:
- tls : the protocol
- ecdhe : ephemeral-ephemeral elliptic curve diffie hellman for key agreement, which brings forward security
- rsa : signature algorithm when certificate authentication is used (for the server)
- aes-128 : cipher used for confidentiality
- gcm : authentication method for the messages (records)
- sha256 : hash algorithm used for the PRF (used for key derivation)
Note that TLS 1.3 uses HKDF instead of a proprietary HMAC based mechanism in TLS 1.2 for the PRF. So although the TLS 1.2 and 1.3 cipher suites you mention may use the same primitives, the protocols differ somewhat (as explained in the initial section of this answer).