ALAKEEL

SSL/TLS

SSL/TLS ist im Kern das, was aus „http://“ → „https://“ macht – also Verschlüsselung + Integrität + (meist) Authentifizierung auf Transportebene.

1. Begriffe & Historie (kurz, aber wichtig für Findings)
  • SSL (Secure Sockets Layer)
    Alte Protokolle: SSL 2.0, 3.0 → sind heute tot (unsicher, sollte komplett deaktiviert sein).
  • TLS (Transport Layer Security)
    Nachfolger von SSL:
    • TLS 1.0 (RFC 2246) – alt, sollte abgeschaltet werden
    • TLS 1.1 – alt, auch abschalten
    • TLS 1.2 – noch weit verbreitet, heute Standard, wenn 1.3 nicht geht
    • TLS 1.3 – modern, vereinfachtes Handshake, nur starke Cipher

Bei Pentest-Reports: immer von TLS sprechen. „SSL“ sagen alle, aber technisch: TLS.

2. Was TLS leistet (Security-Ziele)

TLS liefert (wenn richtig konfiguriert):

  1. Vertraulichkeit
    • Daten sind verschlüsselt, ein MITM kann Inhalt nicht lesen.
  2. Integrität
    • Änderungen am Datenstrom werden erkannt (MAC/AEAD).
  3. Authentizität
    • Client prüft serverseitiges Zertifikat → „Spreche ich wirklich mit diesen Server?“

Was TLS nicht automatisch leistet:

  • Kein Schutz gegen kompromittierten Client (Malware, Keylogger, XSS im Browser).
  • Kein Schutz, wenn Benutzer beliebige Warnungen wegklickt („Zertifikat ungültig, egal“).
  • Kein Schutz gegen Logikfehler in der Applikation.
3. TLS-Grundprinzip: Public-Key + Symmetrische Verschlüsselung
3.1 Warum Hybrid?
  • Asymmetrische Kryptographie (RSA, ECDSA, ECDH):
    • Gut für Authentifizierung & Schlüsselaustausch, aber langsam.
  • Symmetrische Kryptographie (AES, ChaCha20):
    • Sehr schnell für Bulk-Daten.

TLS macht:

  1. Nutzt Asymmetrische Krypto, um einen Shared Secret zu vereinbaren (Handshake).
  2. Davon werden Session Keys abgeleitet.
  3. Datenübertragung selbst läuft mit symmetrischer Verschlüsselung.
4. TLS-Handshake – was passiert grob?
4.1 TLS 1.2 (vereinfacht)
  1. ClientHello
    • Client sagt:
      • „Ich kann diese Protokollversionen (z. B. 1.0–1.2)“
      • „Ich biete diese Cipher Suites an (z. B. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256)“
      • Zufallswert (ClientRandom)
      • Extensions (SNI = Hostname, ALPN, etc.)
  2. ServerHello
    • Server sagt:
      • „Ich nehme diese Version“ (z. B. TLS 1.2)
      • „Ich nehme diese Cipher Suite“
      • Zufallswert (ServerRandom)
  3. Server Certificate
    • Server schickt X.509-Zertifikat (inkl. Chain).
    • Optional: ServerKeyExchange (z. B. bei ECDHE, DH)
    • Optional: CertificateRequest (wenn Client-Zertifikate genutzt werden sollen)
  4. ServerHelloDone
  5. Client Key Exchange
    • Beispiel RSA: Client verschlüsselt einen Premaster-Secret mit dem öffentlichen Schlüssel des Servers.
    • Beispiel ECDHE: Client schickt seinen öffentlichen ECDH-Key.
  6. [Optional: Certificate + CertificateVerify vom Client]
    • Nur bei mutual TLS.
  7. Beide Seiten berechnen aus:
    • Premaster-Secret + ClientRandom + ServerRandom
      → Master Secret → Session Keys.
  8. ChangeCipherSpec / Finished
    • Beide wechseln auf verschlüsselten Modus & beweisen kurz, dass sie denselben Schlüssel kennen.

Ab dann: alles verschlüsselt.

4.2 TLS 1.3 – moderner, kürzer
  • Weniger Round-Trips, keine unsicheren Ciphers mehr.
  • Handshake läuft mit (EC)DHE für Forward Secrecy.
  • Viele alte Konzepte (z. B. getrennte „ChangeCipherSpec“) sind weg.

Für Pentester wichtig:
Bei TLS 1.3 sind viele klassische TLS-Schwächen automatisch entfernt (kein RC4, keine statischen RSA-Schlüsselaustausche etc.).

5. Zertifikate & PKI (für Authentizität)
5.1 Was ist ein Server-Zertifikat?

Ein X.509-Zertifikat enthält u. a.:

  • Subject / SAN (DNS-Name z. B. www.example.com)
  • Öffentlicher Schlüssel
  • Aussteller (CA)
  • Gültigkeitszeitraum
  • Signatur der CA

Browser prüft:

  1. Chain of Trust (Server-Zertifikat → Intermediate → Root CA)
  2. Gültigkeit (Zeit, Revocation)
  3. Hostname (passt CN/SAN zum Host?)
  4. Wird die CA vertraut?
5.2 Typische Zertifikatsprobleme (Findings)
  • Self-signed ohne interne PKI → im Internet-Fall NO-GO.
  • Abgelaufenes Zertifikat.
  • Falscher Hostname (Zertifikat für old.example.com, Seite unter new.example.com).
  • Weak Key:
    • RSA 1024 Bit oder kleiner.
    • Alte Signaturen (MD5, SHA-1).
  • Fehlende Chain:
    • Intermediate CA nicht korrekt ausgeliefert → „Untrusted“ in manchen Clients.

Pentester-Note:
Falsch konfigurierte Zertifikate ermöglichen oft MITM, weil User/Clients eher gewöhnt sind, Warnungen zu ignorieren.

6. Cipher Suites – wo’s „stark“ oder „schwach“ wird

Eine TLS 1.2 Cipher Suite sieht z. B. so aus:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Zerlegt:

  • TLS – Protokoll
  • ECDHE – Key Exchange (Elliptic Curve Diffie-Hellman Ephemeral → Forward Secrecy)
  • RSA – Authentifizierung
  • AES_128_GCM – symmetrische Verschlüsselung (AEAD)
  • SHA256 – Hash
6.1 Schwache Bereiche

Typische No-Gos:

  • RC4 Cipher (…_RC4_…)
  • 3DES (…_3DES_EDE_CBC_…) – wegen Sweet32
  • Nur RSA Key Exchange (TLS_RSA_WITH_…) – keine Forward Secrecy
  • Null-Cipher (…_NULL_…) – keine Verschlüsselung
  • Export Cipher (…_EXPORT_…) – historisch, extrem schwach
  • Alte MACs/Hashes (MD5)
6.2 Was gilt als gut?
  • TLS 1.2: ECDHE (oder DHE) + AES-GCM/ChaCha20-Poly1305 + SHA256/384
  • TLS 1.3: praktisch alle standardmäßigen Cipher sind okay.

Pentester-Aufgabe:
Welche Cipher Suites sind aktiviert? Gibt es schwache Ciphers, alte Protokollversionen? → potentielle Angriffsfläche.

7. Typische Angriffe & Schwachstellen rund um SSL/TLS
7.1 Protokoll-Downgrade

Ziel: Client & Server zwingen, eine ältere, unsichere Version oder Cipher zu verwenden.

Beispiele:

  • Client kann 1.0–1.3, Server kann 1.0–1.2 → MITM manipuliert Hello-Nachrichten → am Ende wird z. B. TLS 1.0 mit schwachem Cipher genutzt.
  • Gegenmaßnahmen:
    • Serverseitig alte Versionen abschalten.
    • TLS_FALLBACK_SCSV (heute Standard).
    • TLS 1.3 Handshake ist robuster gegen Downgrade-Angriffe.

Pentest:
Prüfen, ob Server noch TLS 1.0/1.1 oder gar SSLv3 anbietet. Wenn ja: Finding → „Downgrade möglich“.

7.2 SSL/TLS-Stripping (z. B. sslstrip)

Angriffsidee:

  • Opfer ruft http://example.com auf.
  • MITM antwortet selbst mit HTTP, leitet aber intern zum Server über HTTPS weiter.
  • Nutzer sieht „http“ in der Adressleiste, hat evtl. nichts gemerkt → Passwort & Daten gehen im Klartext über den Angreifer.

Schutz:

  • HSTS (HTTP Strict Transport Security):
    • Server schickt Header: Strict-Transport-Security: max-age=31536000; includeSubDomains
    • Browser merkt sich: Diese Domain nur noch per HTTPS ansprechen.
  • Preload-Listen (z. B. „HSTS Preload List“ bei Browsern).

Pentester-Check:

  • Verwendet die Site HSTS?
  • Wird bei HTTP auf HTTPS weitergeleitet?
  • Können Login-Seiten über HTTP erreicht werden?
7.3 Berühmte TLS-bezogene Bugs (historisch, aber Report-Relevanz)
  • BEAST (TLS 1.0 + CBC) – praktisch durch passende Mitigations/Ciphers obsolet.
  • POODLE (SSLv3 / manche TLS-CBC-Implementierungen) – Grund: SSLv3 killen.
  • CRIME / BREACH – Kompressionsangriffe:
    • TLS-Kompression → anfällig für CRIME.
    • HTTP-Kompression bei reflektierten Geheimnissen → BREACH.
  • Heartbleed (OpenSSL Bug in Heartbeat-Extension):
    • Speicherleak (Private Keys, Secrets, Sessions).
    • Heute hoffentlich gepatcht, aber Forensik/Legacy-Systeme evtl. relevant.
  • ROBOT – Wiederbelebung alter Bleichenbacher-Angriffe auf TLS-RSA-Key-Exchange.

Für aktuelle Pentests geht’s weniger um diese konkreten Namen, mehr darum:

Welche Protokollversionen/Features sind aktiv und könnten solche Klassen von Angriffen ermöglichen?

7.4 Schwache/fehlerhafte Zertifikatsvalidierung beim Client
  • Wenn Client-Anwendungen (Mobile App, API-Client, Embedded) die Zertifikatsprüfung schwach oder gar nicht korrekt implementieren:
    • „accept all certificates“
    • keine Hostname-Validierung
    • keine Chain-Prüfung

Dann ist MITM trivial.
Pentester-Ansatz:

  • Mobile-App/Client dekompilieren/Analysieren.
  • Prüfen, ob Certificate Pinning existiert.
  • Testen, ob MITM-Proxy mit eigenem Root-CA funktioniert:
    • Sollte normal nicht funktionieren, wenn echte Pinning vorhanden ist.
8. TLS aus Pentester-Sicht – was du konkret tust
8.1 Erkennung & Mapping
  • Welche Hosts sprechen HTTPS?
    • Webserver, APIs, interne Dienste, Mail (SMTPS, IMAPS…), VPNs, etc.
  • Welche Ports und Protokolle: 443, 8443, 993, 465, 587, 636 etc.
8.2 Analyse von:
  1. Protokollversionen
    • Unterstützt der Server noch SSLv3/TLS 1.0/1.1? → Finding.
  2. Cipher Suites
    • Schwache Ciphers aktiv? (RC4, 3DES, Export)
    • Keine Forward Secrecy? (TLS_RSA_* ohne (EC)DHE)
  3. Zertifikat
    • Gültigkeit, Hostname, CA, Keylänge, Signaturalgorithmus, Chain korrekt?
  4. Features & Extensions
    • HSTS vorhanden?
    • OCSP-Stapling?
    • ALPN (HTTP/2/3)? – eher Performance/Sicherheitsdesign, selten direktes Finding.
  5. Client-seitige Aspekte
    • Akzeptiert die App beliebige Zertifikate?
    • Deaktiviert/umgeht Pinning?
8.3 Typische Findings, die du formulierst

Beispiele:

  • „Der Server unterstützt veraltete Protokollversionen (TLS 1.0/1.1), die für Downgrade- und Kryptografie-Angriffe anfällig sind.“
  • „Der Server erlaubt schwache Cipher Suites (3DES, ohne Perfect Forward Secrecy).“
  • „Das verwendete Zertifikat nutzt einen unsicheren Signaturalgorithmus (SHA-1).“
  • „Die Anwendung verwendet HTTPS, aber HSTS ist nicht aktiviert, sodass SSL-Stripping-Angriffe möglich sind.“
  • „Die mobile Anwendung validiert Zertifikate nicht korrekt, wodurch MITM-Angriffe ermöglicht werden.“

Dazu immer:

  • Auswirkung (Impact)
  • Angriffsszenario (kurz, kein Exploit-Code)
  • Empfehlung (konkrete Konfigurationsvorschläge auf hoher Ebene)
9. HTTPS ist nicht alles: TLS + Applikationslogik

Wichtige Pentester-Perspektive:

  • Eine perfekte TLS-Konfiguration macht die Web-App nicht automatisch sicher:
    • SQLi, XSS, IDOR, CSRF, Business Logic Bugs – alles weiterhin möglich.
  • TLS schützt nur Transportstrecke.
    → Wenn im Browser XSS ist, oder Passwort per Mail im Klartext verschickt wird, hilft TLS nicht.

Also: TLS ist ein Baustein, aber kein Allheilmittel.

10. Kurze Checkliste für deinen Pentest (TLS-Teil)

Wenn du eine Domain prüfst, geh grob so vor:

  1. Welche TLS-Versionen sind aktiv?
    • Erwünscht: 1.2, 1.3
    • Finding: SSLv2, SSLv3, TLS 1.0, 1.1
  2. Cipher Suites
    • Erwünscht: (EC)DHE + AES-GCM/ChaCha20 + SHA2
    • Finding: RC4, 3DES, Export, keine PFS
  3. Zertifikate
    • Passt Hostname?
    • Nicht abgelaufen?
    • Key ≥ 2048 Bit (RSA)?
    • Keine MD5/SHA-1-Signaturen?
    • Chain komplett?
  4. HSTS & Redirects
    • HTTP → HTTPS-Redirect?
    • Strict-Transport-Security gesetzt (mit sinnvollem max-age)?
  5. Client-Verhalten
    • Web: Warnungen? Mixed-Content?
    • Mobile/API: Zertifikatsvalidierung korrekt? Pinning?
  6. Dokumentation
    • Alles mit Screenshots/Output der Tools untermauern.
    • Risiko bewerten, Empfehlung geben.

In

, , , , , , , , , , ,