Zum Inhalt springen
_CORE
KI & Agentensysteme Unternehmensinformationssysteme Cloud & Platform Engineering Datenplattform & Integration Sicherheit & Compliance QA, Testing & Observability IoT, Automatisierung & Robotik Mobile & Digitale Produkte Banken & Finanzen Versicherungen Öffentliche Verwaltung Verteidigung & Sicherheit Gesundheitswesen Energie & Versorgung Telko & Medien Industrie & Fertigung Logistik & E-Commerce Retail & Treueprogramme
Referenzen Technologien Blog Know-how Tools
Über uns Zusammenarbeit Karriere
CS EN DE
Lassen Sie uns sprechen

SSL/TLS — Sicherheits-Best-Practices für 2014

22. 05. 2014 4 Min. Lesezeit CORE SYSTEMSsecurity
SSL/TLS — Sicherheits-Best-Practices für 2014

April 2014. Der Heartbleed-Bug erschütterte das gesamte Internet. Eine zwei Jahre alte Sicherheitslücke in OpenSSL ermöglichte es Angreifern, den Serverspeicher auszulesen — einschließlich privater Schlüssel und Session-Token. Wenn Sie das nicht dazu gebracht hat, Ihre SSL/TLS-Konfiguration zu überprüfen, wird es nichts mehr schaffen.

Der Stand von SSL/TLS im Jahr 2014

Schauen wir uns die Realität an: Die Mehrheit der tschechischen Websites läuft noch auf HTTP. Die, die HTTPS haben, nutzen oft veraltete Protokolle und schwache Cipher Suites. SSL 3.0 ist noch aktiviert. RC4 ist die „empfohlene” Alternative zum BEAST-Angriff. Und selbstsignierte Zertifikate in internen Systemen sind die Norm.

Das muss sich ändern. Heartbleed war ein Weckruf. Aber das Problem liegt tiefer — schlechte TLS-Konfiguration ist allgegenwärtig, und die meisten Administratoren geben sich mit den Standardeinstellungen zufrieden, die oft löchrig sind.

Schritt 1: SSL 3.0 und älter deaktivieren

SSL 2.0 ist seit Jahren tot. SSL 3.0 sollte es auch sein — es ist anfällig für den POODLE-Angriff (der im Oktober 2014 kommt, aber kluge Admins deaktivieren ihn jetzt schon). Das Mindestprotokoll sollte TLS 1.0 sein, idealerweise TLS 1.2 für moderne Clients.

# SSL/TLS — Sicherheits-Best-Practices für 2014
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:!aNULL:!eNULL:!EXPORT:!RC4:!MD5:!PSK';

# DH parameters — generate your own!
ssl_dhparam /etc/nginx/dhparam.pem;  # openssl dhparam -out dhparam.pem 2048

Schritt 2: Cipher Suites — Die Reihenfolge zählt

Die korrekte Reihenfolge der Cipher Suites ist entscheidend. Der Server sollte bevorzugen:

  • ECDHE Cipher Suites — bieten Forward Secrecy (PFS). Selbst wenn ein Angreifer den privaten Schlüssel erlangt, kann er vergangene Kommunikation nicht entschlüsseln.
  • AES-GCM — authentifizierte Verschlüsselung, schnell auf moderner Hardware mit AES-NI-Instruktionen
  • SHA-256+ — SHA-1 ist auf dem Rückzug; Chrome wird es als unsicher markieren

Was deaktiviert werden muss: RC4 (Bias-Angriffe), MD5 (Kollisionen), EXPORT Ciphers (40-Bit, ein Überbleibsel aus den 1990ern), NULL Ciphers (keine Verschlüsselung) und DES/3DES (langsam, schwach).

Schritt 3: HSTS — HTTPS erzwingen

HTTP Strict Transport Security sagt dem Browser: „Verbinde dich niemals über HTTP mit dieser Website.” Ein einfacher Header, eine dramatische Auswirkung auf die Sicherheit. Eliminiert SSL-Stripping-Angriffe.

# HSTS header — Nginx
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

# Apache
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

Achtung: HSTS ist eine Einbahnstraße. Sobald Sie es mit einem langen max-age aktivieren, werden Browser HTTP für die Dauer der Gültigkeit ablehnen. Beginnen Sie mit einem kurzen max-age (3600) und erhöhen Sie schrittweise.

Schritt 4: Zertifikate — Richtig machen

Nach Heartbleed müssen alle Zertifikate und privaten Schlüssel neu generiert werden. Nicht nur erneuert — ein neues Schlüsselpaar. Das alte könnte kompromittiert sein.

  • RSA 2048-Bit Minimum — 1024-Bit ist unzureichend; NIST empfiehlt seit 2014 mindestens 2048
  • SHA-256-Signatur — SHA-1-Zertifikate werden ab 2015 von Browsern abgestraft
  • Vollständige Kette — servieren Sie Intermediate-Zertifikate, nicht nur das Leaf
  • OCSP Stapling — der Server selbst verifiziert die Zertifikatgültigkeit; schneller als CRL
# OCSP Stapling — Nginx
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

Schritt 5: Testen, testen, testen

Konfiguration ohne Tests ist wertlos. Nutzen Sie diese Tools:

  • SSL Labs Server Test (ssllabs.com) — Zielen Sie auf ein A+-Rating
  • testssl.sh — Offline-Tests über die Kommandozeile
  • nmap –script ssl-enum-ciphers — schnelles Cipher-Suite-Audit
  • openssl s_client — manuelles TLS-Handshake-Debugging

Unsere interne Regel: Kein Server geht ohne SSL-Labs-Rating A in Produktion. Nach Heartbleed auditierten wir alle 47 Produktionsserver. 31 davon hatten ein Rating von B oder schlechter. Innerhalb von zwei Wochen waren alle auf A.

Forward Secrecy — Warum es wichtig ist

Perfect Forward Secrecy (PFS) stellt sicher, dass die Kompromittierung des privaten Schlüssels historische Kommunikation nicht offenlegt. Jede Session verwendet einen einzigartigen ephemeren Schlüssel. Das ist besonders nach Heartbleed entscheidend — wenn die NSA oder jemand anderes verschlüsselten Verkehr aufgezeichnet und später den Schlüssel erlangt hat, kann er ohne PFS alles rückwirkend entschlüsseln.

ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) ist die heute bevorzugte Methode. Sie ist schneller als DHE und bietet das gleiche Sicherheitsniveau mit kürzeren Schlüsseln. Stellen Sie sicher, dass Ihre Cipher Suites mit ECDHE beginnen.

Häufige Fehler, die wir sehen

Bei der Überprüfung von SSL/TLS-Konfigurationen bei tschechischen Unternehmen stoßen wir wiederholt auf dieselben Probleme:

  • Standard-DH-Parameter (1024-Bit) — generieren Sie eigene 2048-Bit
  • Mixed Content — eine HTTPS-Seite lädt HTTP-Ressourcen; der Browser zeigt eine Warnung
  • Fehlende Weiterleitung HTTP → HTTPS — der Benutzer greift über HTTP zu und bleibt dort
  • Wildcard-Zertifikat auf öffentlich zugänglichen Subdomains — Kompromittierung einer = Kompromittierung aller
  • Interne Systeme ohne TLS — „es ist doch hinter der Firewall” (ist es nicht)

SSL/TLS ist nicht optional

Heartbleed war eine Warnung. POODLE kommt in wenigen Monaten. Und Google hat gerade angekündigt, dass HTTPS ein Ranking-Signal wird. Eine korrekte TLS-Konfiguration ist kein Luxus — sie ist Grundlage. Gehen Sie diese Checkliste durch, testen Sie Ihre Server und beheben Sie, was behoben werden muss. Heute, nicht morgen.

ssl/tlsheartbleedsecurityhttpsnginx
Teilen:

CORE SYSTEMS

Wir bauen Kernsysteme und KI-Agenten, die den Betrieb am Laufen halten. 15 Jahre Erfahrung mit Enterprise-IT.

Brauchen Sie Hilfe bei der Implementierung?

Unsere Experten helfen Ihnen bei Design, Implementierung und Betrieb. Von der Architektur bis zur Produktion.

Kontaktieren Sie uns