Teil 2 – Typische Fehler bei der Transportverschlüsselung

Wenn Daten auf der Reise abgehört werden

Stell dir vor, du schickst einen Brief mit wichtigen Informationen – aber statt ihn zu versiegeln, steckst du ihn einfach offen in den Umschlag. Jeder Postbote kann mitlesen.
Genauso unsicher ist es, wenn eine Anwendung sensible Daten ohne Transportverschlüsselung überträgt.


HTTP statt HTTPS

Noch immer gibt es Login-Seiten oder APIs, die HTTP verwenden. Das Problem:

  • Daten werden im Klartext übertragen.
  • Jeder Angreifer im gleichen Netzwerk (z. B. WLAN im Café) kann mitlesen.
  • Passwörter, Tokens oder Cookies sind sofort sichtbar.

Beispiel:

POST http://example.com/login
username=alice&password=secret123

Ein Sniffer wie Wireshark zeigt sofort den Klartext – der Angreifer hat den Account übernommen.


Veraltete Protokolle und Cipher Suites

Selbst bei HTTPS können Fehler passieren, wenn veraltete Versionen im Einsatz sind:

  • SSLv2, SSLv3 – unsicher seit Jahrzehnten.
  • TLS 1.0, TLS 1.1 – seit 2020 von allen großen Browsern deaktiviert.

Auch unsichere Cipher Suites wie RC4 oder 3DES machen die Verschlüsselung angreifbar.

Ein reales Beispiel: Die Schwachstelle POODLE nutzte Schwächen in SSLv3 aus, um Inhalte trotz Verschlüsselung mitzulesen.


Unsichere Zertifikatsprüfung

Transportverschlüsselung ist nur so stark wie die Zertifikatsprüfung.
Fehlerhafte Implementierungen akzeptieren jedes Zertifikat – auch wenn es selbstsigniert oder manipuliert ist.

Beispiel in einer unsicheren Mobile App:

TrustManager[] trustAllCerts = new TrustManager[]{
  new X509TrustManager() {
    public java.security.cert.X509Certificate[] getAcceptedIssuers() { return null; }
    public void checkClientTrusted(...) {}
    public void checkServerTrusted(...) {}
  }
};

Damit akzeptiert die App jedes Zertifikat – ein Angreifer kann sich einfach dazwischenschalten.


Fehlende Zusatzmaßnahmen

Selbst mit TLS gibt es weitere Schutzmechanismen, die oft fehlen:

  • HSTS (HTTP Strict Transport Security):
    Erzwingt, dass ein Browser nur HTTPS nutzt. Ohne HSTS können Angreifer „Downgrade-Angriffe“ versuchen und den Nutzer auf HTTP umleiten.
  • Certificate Pinning:
    Apps und Browser können ein bestimmtes Zertifikat oder eine bestimmte CA „anpinnen“. Fehlt dieses Feature, akzeptieren sie eventuell ein manipuliertes Zertifikat.

Best Practices für sichere Transportverschlüsselung

  • Nur HTTPS – HTTP konsequent auf HTTPS umleiten.
  • TLS 1.3 (oder mindestens TLS 1.2) verwenden.
  • Unsichere Cipher Suites deaktivieren – keine RC4, 3DES, EXPORT-Ciphers.
  • Saubere Zertifikatsprüfung implementieren – niemals trustAllCerts.
  • HSTS aktivieren – schützt gegen Downgrades.
  • Certificate Pinning nutzen – besonders in mobilen Apps.
  • Regelmäßig testen: Tools wie SSL Labs zeigen Schwächen in der TLS-Konfiguration.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert