Aside: that diagram is only correct (or nearly) for TLS 1.0 through 1.2, not 1.3. It mentions, without explanation, the number 3.2, which is the internal version for TLS 1.1, suggesting it is intended to match that version, for the two DHE key exhanges (DHE_RSA and DHE_DSS). But it references CDH, which usually means Cofactor Diffie-Hellman, which TLS does not use -- and in that step it doesn't show $p,g$ as parameters which for these protocols they definitely are. (In 1.3 they still are, but via predefined curves which could be considered the 'source'.) 1.0 and 1.2 are identical for most of the handshake, but vary slightly in the second part of the (shared) key derivation.
- Diffie Hellman Key Exchange
I am fairly certain that this Part can be found in the Exchange of SKE and CKE, since they contain the public Key with Signatures and can be used by the other party to derive a shared key
Basically, yes. SKE contains the parameters (p,g) and publickey which this calls Y but the RFCs call Y_s; CKE contains publickey here X but in RFCs Y_c. The server also provides a signature in SKE, and the client may provide a signature in CV (adjacent to but not in CKE); while these contribute to the overall handshake they don't contribute to DH itself.
I am having trouble identifying this part. Since this part is usually something you would do before exchange a key, i reccon it can only occur in the Part with the CH. However, i fail to see how CH (CHallenge?) is a challenge for the Server S, because usually challenges are solved by using private information
First, the all-caps and mostly-caps items (other than SID = Session Identifier, PRF, and CDH) are clearly abbreviations of the TLS message types:
CH = Client Hello
SH = Server Hello
SKE = Server Key Exchange
CRT = Certificate
CReq = Certificate Request
SHD = Server Hello Done
CKE = Client Key Exchange
CV = Certificate Verify
CCS = Change Cipher Spec
FIN = Finished
See e.g. the summary diagram in RFC 4346 7.3 at page 33. Note Creq in server's first flight, and CRT and CV in client's second flight, are shown in brackets, indicating they are optional; this corresponds to asterisks in the RFC summary diagram.
There are two challenges in the TLS handshake: the client and server randoms, shown here as $r_C$ and $r_S$. These are included in the data signed (server always, client sometimes, as above), and the (shared) key derivation, and the Finished message values (which MAC the handshake).
- Certificate Verify
I know the Certificate consists of Public Key and digital Signature, but how can a Certificate be authenticated here without having established a shared secret yet? I do not see any Certification Authority here as well, so i am clueless
Certificate verification and validation (terms which are often interchanged, although a distinction can be made) as applied to TLS includes several steps, and I'm not sure which your teacher intends you to cover. First off, a certificate (of the type relevant here) contains a publickey and signature, but also much other information. And the cert itself is not authenticated, rather it is used to authenticate something else -- in TLS the server is almost always authenticated by a certificate, and the client sometimes (but rarely) is. And although TLS connections almost always use cert-based authentication, strictly speaking it isn't part of the TLS protocol: TLS only conveys the cert data, leaving its processing up to the relying endpoint(s). TLS can also convey certificate 'status' (i.e. revocation) information, in the form of pre-generated OCSP responses; this is called 'stapling' and has become very common since about 2012, but is not in your diagram. And while each certificate is issued by a Certificate Authority, and the related CRL and/or OCSP information either by or on behalf of the CA, the CA is not involved in the TLS protocol.
For a basic explanation of cert chain usage and validation for HTTPS see my old answer to this Q. A bit more formally:
every certificate is issued and signed by a CA; in practice your server's cert is not signed directly by a root CA, instead there is at least one intermediate CA in between, and the list of certs from your server's cert (or client's when used) through the intermediate(s) to the root is called a chain
each certificate below the root in a chain is verified by verifying its signature using the publickey from the next cert in the chain or the root; and checking a number of items in the certificate data, see RFC5280 section 6; and checking for revocation, for which there are several options, and expiration
the set of root CAs that are trusted can be defined separately for each relier, although typically a system-provided or browser-provided default is used; the root CA information is usually stored as a series of self-signed certficates (although this isn't strictly necessary, see e.g. the Java
CertPathValidator API) and called a 'truststore'
for some TLS applications like HTTPS, the name in the 'leaf' (end-entity) certificate for the server is checked to make sure it identifies the correct server (the one the client wanted to connect to)