Impulse · HTTPS · Websicherheit

HTTPS – Das Schloss, das gar kein Gütesiegel ist

Warum eine verschlüsselte Verbindung wichtig ist – und das kleine Schloss trotzdem nichts über die Vertrauenswürdigkeit einer Webseite sagt.

NoData.ForSale · Impulse · HTTPS · Veröffentlicht 15.08.2026

Wer schon etwas länger im Internet unterwegs ist, erinnert sich vielleicht noch daran.

Man tippte:

http://

Oder einfach:

www.

Und los ging es.

Oben in der Adresszeile war kein Schloss.

Keine Warnung.

Kein Hinweis darauf, dass irgendetwas „nicht sicher“ wäre.

Das Internet funktionierte einfach.

Natürlich war es deshalb nicht sicherer.

Ganz im Gegenteil.

Ein großer Teil des Webs wurde damals vollkommen unverschlüsselt übertragen. Wer technisch an der richtigen Stelle saß, konnte Daten mitlesen oder unter Umständen sogar verändern.

Heute sieht die Welt anders aus.

Aus http:// wurde fast überall:

https://

Und daran hatte ein Projekt einen erheblichen Anteil.

Let's Encrypt.


Als Verschlüsselung plötzlich nichts mehr kosten musste

TLS-Zertifikate gab es natürlich schon lange vor Let's Encrypt.

Doch für kleine Webseiten bedeuteten Zertifikate früher häufig zusätzlichen Aufwand und zusätzliche Kosten.

Dann kam Let's Encrypt.

Die gemeinnützige Zertifizierungsstelle machte Zertifikate kostenlos und vor allem weitgehend automatisierbar. Das erste öffentlich vertrauenswürdige Let's-Encrypt-Zertifikat ging im September 2015 online. (Let's Encrypt)

Die Idee dahinter war ziemlich einfach:

HTTPS sollte nicht länger etwas Besonderes sein.

Jeder Webseitenbetreiber sollte seinen Datenverkehr verschlüsseln können – ohne dafür erst Zertifikate kaufen und kompliziert von Hand verlängern zu müssen.

Let's Encrypt bezeichnet sich selbst bis heute als kostenlose, automatisierte und offene Zertifizierungsstelle. (Let's Encrypt)

Und das hat funktioniert.

HTTPS wurde zum Normalfall.

Das ist grundsätzlich etwas Gutes.


Was HTTPS eigentlich macht

Wenn eine Webseite über HTTPS aufgerufen wird, baut der Browser eine verschlüsselte Verbindung zum Webserver auf.

TLS – die Technik hinter HTTPS – schützt dabei im Wesentlichen drei Dinge:

Vertraulichkeit.

Jemand zwischen dir und dem Webserver soll nicht einfach mitlesen können, was übertragen wird.

Integrität.

Der übertragene Inhalt soll unterwegs nicht unbemerkt verändert werden können.

Und:

Authentizität der Verbindung.

Der Browser prüft anhand des Zertifikats, ob er tatsächlich mit dem Server für die aufgerufene Domain kommuniziert. (Mozilla MDN)

Bei Online-Banking dürfte der Sinn unmittelbar einleuchten.

Ebenso bei:

Shopping.

Passwörtern.

Kundendaten.

Kontaktformularen.

Persönlichen Daten.

Oder allem anderen, was niemand unterwegs mitlesen sollte.

Aber was ist mit einer einfachen Webseite?

Ein bisschen Text.

Ein paar Bilder.

Keine Anmeldung.

Keine Cookies.

Keine Kundendaten.

Braucht die wirklich HTTPS?


Eigentlich schon

Hier muss ich meiner eigenen Skepsis ein kleines Stück widersprechen.

Auch eine reine Content-Webseite profitiert von HTTPS.

Denn es geht nicht nur darum, was du an eine Webseite sendest.

Es geht auch darum, was die Webseite an dich sendet.

Bei einer unverschlüsselten HTTP-Verbindung könnte sich theoretisch jemand zwischen Browser und Server befinden und Inhalte verändern.

Ein Text könnte manipuliert werden.

Ein Download könnte ausgetauscht werden.

Ein eingebundenes Script könnte verändert werden.

Oder jemand könnte zumindest beobachten, welche Inhalte übertragen werden.

HTTPS erschwert genau solche Man-in-the-Middle-Angriffe erheblich, weil sowohl die Verbindung verschlüsselt als auch ihre Integrität geschützt wird. (Mozilla MDN)

Also ja:

Auch NoData.ForSale sollte HTTPS benutzen, obwohl dort niemand sein Online-Banking erledigt.

Das ist sinnvoll.

Trotzdem gibt es etwas an der Entwicklung, das mir bis heute etwas querliegt.


Aus „verschlüsselt“ wurde gefühlt „vertrauenswürdig“

Die großen Browserhersteller wollten HTTPS zum Standard machen.

Mozilla begann beispielsweise bereits 2017 damit, Benutzer deutlicher zu warnen, wenn Passwörter über unverschlüsselte HTTP-Seiten eingegeben werden sollten. (Mozilla Security Blog)

Google ging später noch einen Schritt weiter.

Ab Chrome 68 im Juli 2018 wurden sämtliche HTTP-Webseiten als „Not Secure“ beziehungsweise „Nicht sicher“ gekennzeichnet – unabhängig davon, ob dort überhaupt sensible Daten eingegeben werden konnten. (Chromium Blog)

Aus technischer Sicht verstehe ich die Entscheidung.

Eine unverschlüsselte Verbindung ist nun einmal eine unverschlüsselte Verbindung.

Aber für den normalen Benutzer entstand damit möglicherweise ein anderes Problem.

Denn plötzlich entstand im Umkehrschluss schnell der Eindruck:

Kein Schloss:

Gefährlich.

Schloss:

Sicher.

Und genau das stimmt so nicht.


Der Spitzbube bekommt ebenfalls ein Zertifikat

Nehmen wir einen Betrüger.

Er registriert sich beispielsweise eine Domain, die einer bekannten Bank sehr ähnlich sieht.

Er baut darauf eine täuschend echte Kopie der Bank-Webseite.

Dann beantragt er ein kostenloses Let's-Encrypt-Zertifikat.

Kann er das?

Natürlich.

Wenn er nachweisen kann, dass er die betreffende Domain kontrolliert, kann er grundsätzlich ein sogenanntes Domain-Validated-Zertifikat erhalten.

Let's Encrypt erklärt diesen Punkt selbst bemerkenswert deutlich.

Ein solches DV-Zertifikat sagt nichts über:

die Reputation der Webseite,

die reale Identität des Betreibers

oder die Sicherheit beziehungsweise Vertrauenswürdigkeit ihrer Inhalte aus. (Let's Encrypt)

Das Zertifikat bestätigt im Wesentlichen:

Dieser Server kontrolliert diese Domain.

Nicht:

Dieser Betreiber ist ein guter Mensch.

Und auch nicht:

Diese Webseite ist seriös.

Let's Encrypt prüft zur Ausstellung eines Zertifikats automatisiert, ob der Antragsteller Kontrolle über den betreffenden Domainnamen besitzt. (Let's Encrypt)

Unser Spitzbube kann also eine vollkommen verschlüsselte Phishing-Seite betreiben.

Das Schloss erscheint.

HTTPS funktioniert.

Die Verbindung ist technisch sauber verschlüsselt.

Und trotzdem landen die eingegebenen Zugangsdaten beim Betrüger.


Sicher verbunden mit einem Betrüger

Vielleicht lässt sich das mit einer Straße erklären.

HTTPS sorgt dafür, dass du einen abgeschlossenen Tunnel zu einem bestimmten Haus bekommst.

Niemand unterwegs kann einfach hineinschauen.

Niemand kann dir unterwegs unbemerkt etwas in die Tasche stecken.

Und du kannst überprüfen, dass dieser Tunnel tatsächlich bei der Adresse endet, die du eingegeben hast.

Aber HTTPS beantwortet eine entscheidende Frage nicht:

Wer wohnt eigentlich in diesem Haus?

Wenn du dich bei der Adresse vertan hast und das Haus dem Betrüger gehört, bekommst du trotzdem einen hervorragend verschlüsselten Tunnel direkt zum Betrüger.

Das Schloss funktioniert also vollkommen korrekt.

Es schützt nur vor etwas anderem, als viele Menschen glauben.


Das Schloss bedeutet nicht „vertrauenswürdig“

Das ist wahrscheinlich der wichtigste Satz dieses ganzen Artikels:

HTTPS bedeutet nicht, dass eine Webseite vertrauenswürdig ist.

Es bedeutet im Wesentlichen:

Die Verbindung zwischen deinem Browser und dieser Domain ist verschlüsselt und wurde nicht einfach unterwegs ausgetauscht.

Firefox beschreibt sein Schloss-Symbol entsprechend: Es zeigt an, dass die Verbindung verschlüsselt ist und man mit der Domain verbunden ist, die in der Adresszeile angezeigt wird. (Mozilla Support)

Mehr sollte man in dieses kleine Symbol auch nicht hineininterpretieren.


Wer schaut sich eigentlich noch Zertifikate an?

Ich mache das tatsächlich gelegentlich.

Vielleicht aus alter Gewohnheit.

Vielleicht aus Neugier.

Oder weil mich interessiert:

Wer hat das Zertifikat ausgestellt?

Für welche Domain wurde es ausgestellt?

Wann läuft es ab?

Welche Zertifikatskette steckt dahinter?

Aber mal ehrlich:

Wie viele normale Internetnutzer schauen sich heute noch ein Zertifikat an?

Wahrscheinlich sehr wenige.

Und im Alltag muss man das auch gar nicht ständig tun.

Die technische Prüfung übernimmt der Browser automatisch.

Ist das Zertifikat abgelaufen?

Passt es nicht zur Domain?

Kann die Zertifikatskette nicht bis zu einer vertrauenswürdigen Zertifizierungsstelle geprüft werden?

Dann schlägt der Browser Alarm.

Das ist gut so.

Nur ersetzt diese automatische Prüfung eben nicht unseren eigenen Blick auf die Webseite.


Bei der Bank ist die Adresse wichtiger als das Schloss

Gerade bei Banking, Shopping oder anderen sensiblen Diensten sollte HTTPS heute selbstverständlich sein.

Fehlt dort HTTPS:

Finger weg.

Aber das Vorhandensein von HTTPS reicht allein ebenfalls nicht.

Viel wichtiger ist beispielsweise:

Stimmt die Domain wirklich?

Ist es tatsächlich:

meine-bank.de

oder vielleicht:

meine-bank-kundenservice-irgendwas.de

?

Ein gültiges Zertifikat könnten theoretisch beide besitzen.

Der Browser bestätigt nämlich nicht:

„Das ist deine Bank.“

Er bestätigt:

„Du bist verschlüsselt mit genau der Domain verbunden, die dort oben steht.“

Das ist ein gewaltiger Unterschied.


Und was ist nun mit einfachen Content-Seiten?

Hier komme ich wieder zu meinem ursprünglichen Gedanken.

Ich finde HTTPS gut.

Ich benutze es selbst.

Und heute würde ich auch eine einfache statische Webseite nicht mehr bewusst unverschlüsselt betreiben.

HTTPS schützt schließlich nicht nur Passwörter, sondern auch die Inhalte während der Übertragung.

Trotzdem kann ich nachvollziehen, warum die Warnung „Nicht sicher“ bei einer vollkommen harmlosen statischen Webseite etwas überzogen wirken kann.

Denn eine Seite mit einem Kochrezept oder einem Text über digitale Souveränität ist nicht automatisch gefährlich, nur weil sie noch über HTTP ausgeliefert wird.

Ihre Verbindung ist unsicher.

Das ist technisch etwas anderes als:

Diese Webseite ist gefährlich.

Vielleicht hätte man diesen Unterschied den Nutzern etwas besser erklären können.


Das eigentliche Problem ist unsere Interpretation

Let's Encrypt hat etwas Großartiges geschaffen.

Kostenlose Zertifikate und automatische Erneuerungen haben entscheidend dazu beigetragen, verschlüsselte Verbindungen im Web zum Normalfall zu machen. (Let's Encrypt)

Auch die Browserhersteller hatten einen nachvollziehbaren Grund, Webseitenbetreiber in Richtung HTTPS zu bewegen.

Das Ergebnis ist objektiv ein besser geschütztes Internet.

Nur sollten wir eines nicht vergessen:

Verschlüsselung und Vertrauen sind zwei verschiedene Dinge.

Eine seriöse Webseite kann HTTPS benutzen.

Eine unseriöse Webseite ebenfalls.

Eine Bank kann ein gültiges Zertifikat besitzen.

Eine Phishing-Seite ebenfalls.

HTTPS schützt den Transport.

Nicht den gesunden Menschenverstand.


NoData // Souveränitätscheck

Das kleine Schloss im Browser ist wichtig.

Aber vielleicht haben wir ihm über die Jahre etwas zu viel Bedeutung gegeben.

Es sagt:

Meine Verbindung zu dieser Domain ist verschlüsselt.

Es sagt nicht:

Dieser Webseite kannst du vertrauen.

Vielleicht sollten wir deshalb wieder ein wenig häufiger nach oben in die Adresszeile schauen.

Nicht unbedingt auf das Schloss.

Sondern auf das, was danebensteht.

Die Domain.

Denn am Ende hilft die beste Verschlüsselung nichts, wenn man seine Zugangsdaten perfekt verschlüsselt direkt an den falschen Empfänger sendet.

Das Schloss schützt den Weg.

Wo dieser Weg endet, sollten wir trotzdem selbst im Blick behalten.


Hörtipp: „Passwort“ von heise security

Wer sich etwas tiefer mit Zertifikaten, PKI und den teilweise erstaunlich komplizierten Mechanismen hinter unserem kleinen Browser-Schloss beschäftigen möchte, dem kann ich den Podcast „Passwort – der Podcast von heise security“ empfehlen.

Dr. Christopher Kunz und Sylvester Tremmel beschäftigen sich dort regelmäßig mit IT-Sicherheit und immer wieder auch sehr ausführlich mit Zertifikaten und der Public-Key-Infrastruktur. (Passwort Podcast)

Eine passende Folge ist beispielsweise:

„Zertifikate sind schwierig, Malwarenamen auch“ vom 29. Januar 2025. (Passwort Podcast)

Auch in neueren Folgen taucht das Thema PKI regelmäßig wieder auf – etwa im Juli 2026 bei Änderungen rund um Let's Encrypt und andere Zertifizierungsstellen. (Passwort Podcast)

Quellen

Let's Encrypt

Offizielle Projektseite
Kostenlose, automatisierte und offene Zertifizierungsstelle.

https://letsencrypt.org/

About Let's Encrypt
Hintergrund zum Projekt und seinem Ziel, HTTPS möglichst breit verfügbar zu machen.

https://letsencrypt.org/about/

10 Years of Let's Encrypt Certificates
Rückblick auf das erste öffentlich vertrauenswürdige Let's-Encrypt-Zertifikat im September 2015.

https://letsencrypt.org/2025/12/09/10-years

The CA's Role in Fighting Phishing and Malware
Besonders interessant für diesen Artikel: Let's Encrypt erklärt selbst, dass ein Domain-Validated-Zertifikat keine Aussage über Reputation, Identität oder Sicherheit einer Webseite trifft.

https://letsencrypt.org/2015/10/29/phishing-and-malware

Challenge Types
Erklärung, wie Let's Encrypt überprüft, ob ein Antragsteller Kontrolle über eine Domain besitzt.

https://letsencrypt.org/docs/challenge-types/


Google / Chromium

A secure web is here to stay
Google kündigte an, ab Chrome 68 im Juli 2018 sämtliche HTTP-Seiten als „Not Secure“ zu kennzeichnen.

https://blog.chromium.org/2018/02/a-secure-web-is-here-to-stay.html

Evolving Chrome's security indicators

https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html


Mozilla

Communicating the Dangers of Non-Secure HTTP
Mozilla über die Einführung deutlicher Warnungen bei unverschlüsselten Webseiten.

https://blog.mozilla.org/security/2017/01/20/communicating-the-dangers-of-non-secure-http/

How do I tell if my connection to a website is secure?
Mozilla erklärt, was das Schloss-Symbol tatsächlich aussagt.

https://support.mozilla.org/en-US/kb/how-do-i-tell-if-my-connection-is-secure

Transport Layer Security – MDN

https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Transport_Layer_Security


heise security

Passwort – der Podcast von heise security

https://passwort.podigee.io/

Zertifikate sind schwierig, Malwarenamen auch

https://passwort.podigee.io/24-zertifikate-sind-schwierig-malwarenamen-auch

News mit Bombenbauwürmern, Zertifikatsketten und Geistersendern

https://passwort.podigee.io/61-news-mit-bombenbauwurmern-zertifikatsketten-und-geistersendern