diff --git a/IN0042_ITSEC/ITsec.yaml b/IN0042_ITSEC/ITsec.yaml index 61dfbed..344e854 100644 --- a/IN0042_ITSEC/ITsec.yaml +++ b/IN0042_ITSEC/ITsec.yaml @@ -811,9 +811,10 @@ cards: 4. h2 = h("admin") mit internem zustand von h gleich h1 - type: markdown + id: 112 # (generated) front: | Angenommen das jedes Zeichen aus einem Passwortalphabet M gleich wahrscheinlich ist. Wie berechnet man die Entropie für ein Password der Länge L? - back: | - log_2(|M|^L) \ No newline at end of file + back: |- + log_2(|M|^L) diff --git a/IN0042_ITSEC/TLS.yaml b/IN0042_ITSEC/TLS.yaml index 3638418..d45a48c 100644 --- a/IN0042_ITSEC/TLS.yaml +++ b/IN0042_ITSEC/TLS.yaml @@ -4,8 +4,9 @@ id: 1708962331 cards: - type: md_basic + id: 0 # (generated) front: Wann ist eine TLS Verbindung kompromitiert? - back: | + back: | Die Authenitizität des Servers basiert auf der Certificate Chain. Beispielsweise würde die TLS Verbindung durch eine **kompromitierte Certificate Authority (CA)** nicht mehr sicher sein. @@ -14,6 +15,7 @@ cards: **Server kompromitiert** wurde. - type: md_basic + id: 1 # (generated) front: | Ein Angreifer hat alle Nachrichten eines TLS-Handshakes abgefangen. Er maskiert sich nun als Server und sendet dem Client beim nächsten Handshake in @@ -25,6 +27,7 @@ cards: Rc des Clients im MAC berücksichtigt. - type: md_basic + id: 2 # (generated) front: | Kann der Server auch ein Zertifikat vom Client bei TLS erwarten? back: | @@ -36,9 +39,10 @@ cards: signiert. - type: md_basic - front: Angenommen eine stateful request wird via 0-RTT TLS an den Server - verschickt. Zu welchen Problem kann es hierbei kommen? - back: | - Da 0-RTT-Daten ohne vollständige Verhandlung gesendet werden, kann ein - Angreifer diese Daten abfangen und erneut an den Server senden. Der Server - könnte diese erneut gesendeten Daten als neue, legitime Anfragen behandeln. \ No newline at end of file + id: 3 # (generated) + front: Angenommen eine stateful request wird via 0-RTT TLS an den Server verschickt. + Zu welchen Problem kann es hierbei kommen? + back: |- + Da 0-RTT-Daten ohne vollständige Verhandlung gesendet werden, kann ein + Angreifer diese Daten abfangen und erneut an den Server senden. Der Server + könnte diese erneut gesendeten Daten als neue, legitime Anfragen behandeln.