Aktuelles

Meine Seite is sischa - trotzdem ist das Schloss-Symbol in der Adresszeile des Browsers kein TÜV-Siegel

Jeder kennt noch Norbert Blüms Rentenspruch, aus dem die Überschrift abgeleitet ist. Und wie wir heute alle wissen, "sischa" ist gar nix, weder bei der Rente, noch im Internet. Dennoch gibt es hier wie dort Begriffe, die sich hartnäckiger halten als ein Wasserfleck an der Altbaudecke. „SSL-Zertifikat“ ist so einer. Hosting-Anbieter verkaufen es wie geschnitten Brot, Kunden bestellen es, Agenturen schreiben es in Angebote und kaum jemand merkt, dass das Protokoll, nach dem das Ding benannt ist, seit rund zehn Jahren offiziell beerdigt ist. Wer heute „SSL“ sagt, meint fast immer TLS. Das wäre nur eine sprachliche Schlamperei, wenn auf manchen Servern nicht tatsächlich noch die Leichen von damals herumliegen würden.

Zeit also für eine kleine Aufräumaktion: Was ist der Unterschied zwischen SSL und TLS, welche Versionen dürfen Sie heute noch guten Gewissens anbieten, was passiert beim Handshake und warum ist ein grünes Schloss im Browser eben kein TÜV-Siegel für die ganze Website?

Kurze Ahnengeschichte: von SSL zu TLS

SSL (Secure Sockets Layer) wurde Mitte der Neunziger von Netscape entwickelt, um das damals noch recht naive Web abhörsicher zu machen. Version 1.0 hat das Labor nie verlassen, Version 2.0 erschien 1995 und war so löchrig, dass ein Jahr später SSL 3.0 nachgeschoben wurde. 1999 übernahm die IETF das Ruder, und weil man das Ganze als offenen Standard neu aufstellen wollte, bekam es einen neuen Namen: TLS (Transport Layer Security). TLS 1.0 ist technisch gesehen ein leicht renoviertes SSL 3.0 mit neuem Türschild.

Seitdem hat sich viel getan. Angriffe mit klangvollen Namen wie BEAST, POODLE, CRIME, Lucky Thirteen oder DROWN haben nach und nach gezeigt, welche Bausteine der alten Protokolle nicht mehr zu retten sind. SSL 2.0 wurde 2011 per RFC 6176 verboten, SSL 3.0 folgte 2015 mit RFC 7568 - nach POODLE war da nichts mehr zu machen. TLS 1.0 und TLS 1.1 hat die IETF im März 2021 mit RFC 8996 offiziell für veraltet erklärt. Die großen Browser hatten sie da schon längst rausgeworfen.

Übrig bleiben genau noch zwei Versionen, über die man ernsthaft reden muss.

Die Versionen im Überblick

Protokoll	Erschienen	Status	Empfehlung
SSL 2.0	1995	verboten seit 2011 (RFC 6176)	sofort abschalten
SSL 3.0	1996	verboten seit 2015 (RFC 7568), POODLE	sofort abschalten
TLS 1.0	1999	veraltet seit 2021 (RFC 8996)	abschalten
TLS 1.1	2006	veraltet seit 2021 (RFC 8996)	abschalten
TLS 1.2	2008	weit verbreitet, sicher bei sauberer Konfiguration	nur mit ECDHE und AEAD-Ciphern anbieten
TLS 1.3	2018	aktueller Standard	bevorzugen

TLS 1.2: der zuverlässige Kombi, wenn man ihn pflegt

TLS 1.2 ist so etwas wie der gut gewartete Kombi in der Firmenflotte: nicht mehr ganz jung, aber zuverlässig - vorausgesetzt, jemand kümmert sich darum. Das Problem von TLS 1.2 ist nicht das Protokoll an sich, sondern seine Großzügigkeit. Es erlaubt eine Menge Cipher Suites, die man heute nicht mehr anfassen sollte: RSA-Schlüsselaustausch ohne Forward Secrecy, CBC-Modi, RC4, 3DES, SHA-1. Wer TLS 1.2 mit der Standardkonfiguration einer Linux-Distribution von 2017 betreibt, bietet unter Umständen ein Museum an.

Sauber konfiguriert heißt: Schlüsselaustausch ausschließlich über ECDHE (für Forward Secrecy) und Verschlüsselung ausschließlich über AEAD-Verfahren wie AES-GCM oder ChaCha20-Poly1305. Dann ist TLS 1.2 weiterhin völlig in Ordnung - und für ältere Clients, API-Partner oder Industriegeräte oft schlicht noch nötig.

TLS 1.3: weniger ist mehr

TLS 1.3 ist das Ergebnis eines seltenen Ereignisses in der IT: Man hat sich getraut, Dinge wegzuwerfen. Statische RSA- und Diffie-Hellman-Schlüsselaustausche, CBC, RC4, SHA-1 für Signaturen, Kompression, Renegotiation - alles raus. Übrig geblieben sind fünf Cipher Suites, die alle AEAD verwenden, und Forward Secrecy ist nicht mehr optional, sondern Pflicht. Man kann TLS 1.3 also deutlich schwerer falsch konfigurieren, was angesichts mancher Serverkonfigurationen da draußen ein echter Segen ist.

Dazu kommt Tempo: Der Handshake braucht nur noch einen Round Trip statt zwei, und große Teile davon - inklusive des Serverzertifikats - laufen bereits verschlüsselt. Im Juli 2026 hat die IETF mit RFC 9846 eine überarbeitete Fassung der TLS-1.3-Spezifikation veröffentlicht; am Grundprinzip ändert das nichts, es räumt vor allem Unklarheiten auf.

Ein Wort zu 0-RTT (Early Data): Damit kann ein Client bei einer Wiederaufnahme der Verbindung schon Daten mitschicken, bevor der Handshake abgeschlossen ist. Schnell, aber anfällig für Replay-Angriffe. Für einen GET-Request auf ein Bild kein Problem, für einen POST, der eine Bestellung auslöst, sehr wohl. Wenn Sie es nicht gezielt brauchen: ausgeschaltet lassen.

Was beim Handshake eigentlich passiert

Der TLS-Handshake ist das Vorgespräch, bevor auch nur ein Byte Nutzdaten fließt. Vereinfacht am Beispiel von TLS 1.3:

1. Der Client schickt ein „ClientHello“ mit den unterstützten TLS-Versionen, Cipher Suites und gleich einem Schlüsselanteil für den Diffie-Hellman-Austausch.
2. Der Server antwortet mit einem „ServerHello“, wählt Version und Verfahren aus und schickt seinen eigenen Schlüsselanteil. Ab hier können beide einen gemeinsamen Sitzungsschlüssel berechnen, ohne dass dieser jemals übertragen wurde.
3. Bereits verschlüsselt folgen das Zertifikat des Servers und eine Signatur, mit der er beweist, dass er den passenden privaten Schlüssel besitzt.
4. Der Client prüft das Zertifikat: Ist es von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt, noch gültig und passt es zum aufgerufenen Hostnamen?
5. Beide Seiten bestätigen den Abschluss mit einer „Finished“-Nachricht. Ab jetzt läuft die eigentliche Kommunikation verschlüsselt und integritätsgeschützt.

Die drei Schutzziele, die TLS damit liefert: Vertraulichkeit (niemand kann mitlesen), Integrität (niemand kann unbemerkt etwas verändern) und Authentifizierung (Sie sprechen tatsächlich mit dem Server, der im Zertifikat steht).

Post-Quanten-Kryptografie: schon da, bevor Sie gefragt haben

Kleiner Exkurs, weil es gerade aktuell ist: Ein großer Teil des Browser-Traffics wird inzwischen mit einem hybriden Schlüsselaustausch abgesichert, der klassisches X25519 mit dem Post-Quanten-Verfahren ML-KEM kombiniert. Die Gruppe heißt X25519MLKEM768, ist seit August 2026 als RFC 10024 standardisiert und in aktuellen Browsern bereits voreingestellt. Hintergrund ist das Szenario „heute mitschneiden, später entschlüsseln“ - wer verschlüsselten Verkehr jetzt speichert, könnte ihn mit einem künftigen Quantencomputer knacken.

Serverseitig brauchen Sie dafür OpenSSL ab Version 3.5. Debian 12 liefert noch OpenSSL 3.0 aus, Debian 13 bereits 3.5. Unterstützt Ihr Server die Hybrid-Gruppe nicht, fallen die Browser einfach auf klassisches X25519 zurück - nichts bricht, Sie verschenken nur Zukunftssicherheit. Wichtig: Das betrifft nur den Schlüsselaustausch. Die Zertifikate selbst sind weiterhin klassisch signiert.

Wo TLS Ihnen jeden Tag begegnet

HTTPS ist nur der sichtbarste Fall. TLS steckt außerdem in:

• API-Verbindungen zwischen Shop, Zahlungsanbieter und Warenwirtschaft
• E-Mail: SMTP mit STARTTLS, IMAPS, POP3S, Submission auf Port 465 und 587
• Datenbankverbindungen, etwa MySQL oder PostgreSQL über TLS
• VPN-Lösungen, LDAPS, FTPS, MQTT im IoT-Umfeld
• HTTP/3 und QUIC, wo TLS 1.3 fest eingebaut ist

Und genau hier liegt eine typische Falle: Die Website ist vorbildlich konfiguriert, aber der Mailserver auf derselben Maschine bietet fröhlich noch TLS 1.0 an, weil die Postfix-Konfiguration seit 2016 niemand mehr angesehen hat.

Das Schloss-Symbol lügt nicht, es sagt nur weniger, als Sie denken

Ein gültiges Zertifikat bedeutet: Die Verbindung zwischen Ihrem Browser und genau diesem Server ist verschlüsselt, und der Server gehört zur angegebenen Domain. Mehr nicht. Es sagt nichts darüber, ob hinter der Domain ein seriöses Unternehmen oder ein Phishing-Kit steht. Domain-validierte Zertifikate gibt es kostenlos und automatisiert in Minuten - und Betrüger nutzen sie selbstverständlich auch. Ein Phishing-Shop mit HTTPS ist heute nicht die Ausnahme, sondern der Normalfall.

Genauso wenig sagt das Schloss etwas über den Zustand des Servers aus. Ein veraltetes WordPress mit verwundbarem Plugin wird nicht sicherer, weil die Verbindung dorthin verschlüsselt ist. Die SQL-Injection kommt dann eben verschlüsselt an. TLS schützt den Transportweg, nicht das Ziel.

Zertifikate: bald im Monatsrhythmus

Apropos Zertifikate: Wer seine noch manuell erneuert, sollte sich langsam etwas überlegen. Das CA/Browser Forum hat 2025 mit Ballot SC-081v3 beschlossen, die maximale Laufzeit öffentlicher TLS-Zertifikate schrittweise zu verkürzen. Seit dem 15. März 2026 sind es höchstens 200 Tage, ab dem 15. März 2027 noch 100 Tage und ab dem 15. März 2029 nur noch 47 Tage. Spätestens dann ist manuelle Verlängerung kein Prozess mehr, sondern ein Ausfall mit Ansage. Automatisierung per ACME - Let's Encrypt, certbot, acme.sh oder die eingebaute Funktion Ihres Hosting-Panels - ist keine Kür mehr, sondern Pflicht.

Konfiguration in der Praxis

Eine solide Basiskonfiguration für nginx sieht etwa so aus:

ssl_protocols TLSv1.2 TLSv1.3;  # Nur relevant für TLS 1.2 - TLS 1.3 bringt eigene, sichere Suites mit ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305; ssl_prefer_server_ciphers off;  # Hybrid-PQ-Gruppe nur mit OpenSSL 3.5 oder neuer eintragen, # sonst startet nginx nicht ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1:secp384r1;  ssl_session_tickets off; ssl_early_data off;  add_header Strict-Transport-Security "max-age=63072000" always;

Und das Pendant für Apache:

SSLProtocol -all +TLSv1.2 +TLSv1.3 SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305 SSLHonorCipherOrder off SSLSessionTickets off  Header always set Strict-Transport-Security "max-age=63072000"

Wer nicht bei jedem Server neu nachdenken möchte, findet beim Mozilla SSL Configuration Generator fertige Vorlagen für die gängigen Webserver. Für den deutschen Behörden- und Compliance-Kontext ist die Technische Richtlinie TR-02102-2 des BSI die maßgebliche Referenz.

Prüfen statt hoffen

Konfiguration ist das eine, was der Server tatsächlich anbietet, das andere. Ein paar Werkzeuge, die in keinem Admin-Werkzeugkasten fehlen sollten:

# Welche Protokolle und Cipher bietet der Server an? nmap --script ssl-enum-ciphers -p 443 example.com  # Ausführlicher Rundumcheck inkl. bekannter Schwachstellen testssl.sh example.com  # Wird TLS 1.3 ausgehandelt - und mit welcher Gruppe? openssl s_client -connect example.com:443 -tls1_3 </dev/null 2>/dev/null | grep -E "Protocol|group"  # Mailserver nicht vergessen testssl.sh --starttls smtp mail.example.com:25

Für öffentlich erreichbare Websites ist der SSL Server Test von Qualys SSL Labs der Klassiker - inklusive Schulnote, die man dem Kunden auch ohne Fachchinesisch zeigen kann.

Tür zu!

Gerade in Zeiten, in denen sich die ganze Welt gegenseitig zu hacken scheint: Sagen Sie meinetwegen weiter „SSL-Zertifikat“, das tun alle, und das Zertifikat selbst ist ohnehin protokollneutral. Aber bieten Sie kein SSL mehr an. Und auch kein TLS 1.0 oder 1.1.

Die Kurzfassung für den Monitor-Rand:

• TLS 1.3 bevorzugen.
• TLS 1.2 nur mit ECDHE und AEAD-Ciphern.
• SSL 2.0, SSL 3.0, TLS 1.0 und TLS 1.1 abschalten - auch auf Mail-, Datenbank- und sonstigen Diensten.
• Zertifikatserneuerung automatisieren, bevor die 100-Tage-Grenze 2027 zuschlägt.
• Regelmäßig prüfen, was Ihre Systeme tatsächlich anbieten, statt sich auf die Konfiguration von vor fünf Jahren zu verlassen.

Denn eine verschlüsselte Verbindung ist nur so sicher wie ihre technische Umsetzung. Und die beste Verschlüsselung der Welt hilft nichts, wenn am anderen Ende ein Server steht, den seit drei Jahren niemand mehr gepatcht hat.

Quellen und weitere Informationen:

• Encryption Consulting - SC-081v3 Zeitplan
• Scott Helme - Shorter certificates are coming
• PostQuantum.com - RFC 10024
• Cloudflare - PQC-Unterstützung
• Jacar - PQC-TLS-Adoption (Debian/OpenSSL-Versionen)

09.11.2026