Wikipedia:Technik/Netzwerk/Verschlüsselte Verbindung

Verschlüsselte Verbindung (HTTPS)

---

Diese Projektseite stellt zur verschlüsselten Verbindung im Wiki technische Einzelheiten, Hintergrundinformationen sowie die geschichtliche Entwicklung zusammen.

Einführende Informationen sind auf Hilfe:Verschlüsselte Verbindung beschrieben.

„Verschlüsselte Verbindung“ meint den Zugriff auf Wiki-Seiten mittels „HTTPS“ (TLS).

Erkennbar ist das unter anderem daran, dass die URL (wie meist in der Browser-Adresszeile sichtbar) mit https:// beginnt.

Seit Juni 2015 ist https das ausschließliche Kommunikationsprotokoll für Wikipedia und alle Wikis der WMF.

Geschichtliche Entwicklung

Begonnen hatte der Einsatz der verschlüsselten Verbindungen mit einem einzigen separaten Server für alle Wikis der WMF.

Oktober 2011 – Neue Domain

• Bis Anfang Oktober 2011 hatte die URL des Secure Server begonnen mit:

  https://secure.wikimedia.org/wikipedia/…

• Das wurde geändert; der richtige Pfad ist jetzt gleich dem der normalen URL. Nur noch im zu Beginn stehenden Protokoll – also durch http: oder https: – unterschieden sich beide URL.
• Die veralteten Adressen sollen beim Besuch weiterleiten; das bedeutet aber nicht zwingend, dass jede URL einer Ressource (wie die von Bildern oder Skripten) auf dem alten Weg funktionstüchtig bleibt. Besser ist es, nach und nach die URL anzupassen – wobei die Programmierung etwa in JavaScript deutlich vereinfacht wird, weil die Unterscheidung in zwei Zugriffsarten und Konstruktion unterschiedlicher URL künftig entfällt.
• Nach mehr als einem Jahr Übergangsphase wurden ab Mitte November 2012 alle besuchten Seiten-URL mit secure.wikimedia.org über die Weiterleitung hinaus umgeschrieben auf die entsprechende neue Adresse unter https (gerrit:13429). Damit ist es nicht mehr möglich, dass man sich auf einer Seite mit secure.wikimedia.org befindet; Benutzerskripte, die darauf Rücksicht genommen hatten, brauchen dies nun nicht mehr abzuprüfen. In der Adresszeile des Browsers und in der Seitenumgebung kann secure.wikimedia.org nicht mehr auftreten.

August 2013 – Anmeldung nur noch verschlüsselt

Seit August 2013 erfolgte jede Anmeldung eines Benutzers mittels HTTPS. Damit wird das Passwort nur noch verschlüsselt übertragen.

Die angemeldeten Benutzer hatten von August 2013 bis 12. Juni 2015 dann die Möglichkeit, in den Benutzer-Einstellungen auf der Registerkarte „Benutzerdaten“ beim Feld „Wenn angemeldet, immer eine sichere Verbindung benutzen.“ das voreingestellte Häkchen zu entfernen. Damit würden anschließend die Seiten nur über unverschlüsseltes HTTP übertragen. Andernfalls bliebe man im verschlüsselten Modus.

Wer sich für den verschlüsselten Modus entschieden hatte, erhielt für die Sitzung ein Cookie forceHTTPS mit dem Inhalt 1 (und einen weiteren für 30 Tage dewikiforceHTTPS mit dem Inhalt true). Besuchte man nun eine Wiki-Seite unter http:// (etwa als Ergebnis einer Suchmaschine, oder weil irgendwo die Wikipedia zitiert wird), so wird diese Seite unter https:// neu aufgebaut. Dadurch gibt es hier wieder eine gültige Anmeldung.

Juli 2014 – Perfect Forward Secrecy

Seit 1. Juli 2014 werden verschlüsselte HTTP-Verbindungen zu allen Wiki-Projekten der WMF mit Perfect Forward Secrecy zusätzlich abgesichert.

Sollte also in Zukunft ein Geheimdienst/Bösewicht den geheimen Schlüssel der Wikimedia Foundation ergattern, können zumindest keine durch Geheimdienst/Bösewicht gespeicherten Übertragungsdaten der Vergangenheit entschlüsselt werden.

Juni 2015 – nur noch verschlüsselte Verbindungen

Seit dem 12. Juni 2015 entfällt die Möglichkeit für angemeldete Benutzer, die Seiten selbst über http abzurufen.

Mitte 2015 – HTTP Strict Transport Security (HSTS)

Zur Jahresmitte antworten alle Wiki-Server der WMF mit HSTS:

• Strict-Transport-Security – max-age=31536000; includeSubDomains; preload
• Der Zeitraum sind 365 Tage.

Das bewirkt, das spätestens mit dem ersten Besuch einer Wiki-Seite über einfaches http der Browser sich merkt, dass er nunmehr bei jeder weiteren Kontaktaufnahme von vornherein https verwenden soll, während ansonsten die volle URL der kontaktierten Wiki-Seite noch unverschlüsselt über das Netz übertragen wurde (etwa wenn einem http-Link in einem Dokument oder einer fremden Website gefolgt wurde). Nunmehr lässt sich nur noch beobachten, dass jemand mit einer Wiki-Domain Kontakt aufnimmt, nicht aber welche Seite angefordert wird.

Securing access to Wikimedia sites with HTTPS by default.

Browser-Cache

Die Verschlüsselung betrifft ausschließlich den Transportweg. Im Übrigen werden mittels https übertragene Seiten und Dateien genauso im Browser-Cache zur schnellen Wiederverwendung abgelegt wie unter http und sind auch genauso bei wiederholter Abforderung einer URL nutzbar.

Im Internet Explorer gibt es eine Konfigurationseinstellung, gemäß der über https übertragene Ressourcen nicht auf der Festplatte abgelegt werden sollen. Dies ist jedoch wohl standardmäßig nicht aktiviert. Hintergrund war, dass damals bei verschlüsselt übertragenen Daten (etwa Kontoauszüge) ein besonderes Schutzbedürfnis vermutet werden konnte und diese Informationen nicht in falsche Hände gelangen sollen, wenn die Festplatte verloren oder sonst unbefugt gelesen wird. Allerdings nutzen moderne Webseiten und Browser heute differenziertere Techniken; nur die wirklich sensiblen Daten wie Geldbeträge werden ggf. nicht auf die Festplatte geschrieben, während das Firmenlogo der Bank im Cache gespeichert werden kann und nicht jedes Mal erneut von der Bank heruntergeladen werden muss.

Gründe für verschlüsselte Verbindungen

In folgenden Situationen ist die Nutzung der verschlüsselten Verbindung besonders sinnvoll:

• Arbeit an öffentlichen Hotspots.
  Hier kann jeder Anwesende über http:// mitlesen; dann sollte man alle Aktivitäten mit https abwickeln. Das Einloggen über http ist nur mäßig zu schützen; es gibt eine Minimalsicherheit für das Passwort, die aber nicht mit den Standards etwa bei Finanztransaktionen zu vergleichen ist. (Nebenbei gilt das auch für ein mangelhaft geschütztes privates oder berufliches WLAN – hier wäre allerdings Wikipedia-Benutzung noch das geringste Problem für die eigenen Daten.)
• Arbeitet man mit TUSC und den zugehörigen Skripten, steht neben dem Benutzernamen auch das TUSC-Passwort im Klartext in der URL und ist über http für alle Zwischenstationen problemlos lesbar.
• Benutzung von Netzwerken einer Institution oder Firma, deren Administratoren nicht im Detail über die Aktivitäten informiert sein sollen.
  Alle am Netzwerk-Betrieb Beteiligten wissen immer, dass mit einem Wiki-Server kommuniziert wurde, und in welchem Umfang. Es sind jedoch keine detaillierten URL sichtbar, insbesondere nicht die Namen der Seiten oder transferierte Inhalte. Allerdings können Fachleute an der Richtung der Datenvolumina auf Anhieb erkennen, ob Wiki-Seiten nur gelesen oder auch bearbeitet wurden.
• Proxy-Server
  Ähnlich wie ein Browser-Cache können die beteiligten Zwischenstationen bei großen Netzwerken oder Providern häufig abgefragte Ressourcen (etwa Bilder mit Logos) zwischenspeichern und kontaktieren dann nicht bei jeder Anfrage den Wiki-Server. Das kann dazu führen, dass den Endbenutzern trotz ausdrücklicher Nachfrage veraltete Versionen ausgeliefert werden, falls Server oder Browser nicht standardkonform funktionieren. Da unterwegs die URL der abgerufenen Seiten nicht sichtbar sind, kann eine Zwischenstation auch nicht erkennen, ob der Inhalt zu dieser URL schon einmal abgerufen wurde und muss die Anfrage immer an den Wiki-Server weiterleiten. Normalerweise stellen die Wiki-Seiten durch geeignete Mechanismen sicher, dass alle Ressourcen mit Ausnahme zusätzlicher Benutzerskripte in der aktuellen Version eingebunden werden.
• Vertrauliche Kommunikation durch Administratoren oder höhere Funktionsträger sowie administrative Maßnahmen.
  Die normalen Aktivitäten der Benutzer sind anschließend ohnehin öffentlich sichtbar auf Seiten und Versionsgeschichten; nur die Zuordnung zu einer realen Person darf nicht ermöglicht werden.

Um es selbst Regierungen nahezu unmöglich zu machen, auch nur Suchanfragen oder gar Bearbeitungen mitzulesen, wurde im Sommer 2013 die Infrastruktur der Wikimedia für die standardmäßige Verwendung von https: ausgebaut.

• Für die folgenden Sprachversionen gilt dies vorläufig nicht: Chinesisch (zh.*), Persisch (fa.*), Gilaki (glk.*), Kurdisch (ku.*), Mazanderani (mzn.*), Sorani Kurdisch (ckb.*) – es ist aber geplant, den Bearbeitern außerhalb betroffener Staaten die Nutzung sicherer Verbindungen zu ermöglichen.

Gelegentlich wurde früher argumentiert, der damals einzige „Secure Server“ sei langsamer und öfter unerreichbar.

• Das war 2010 wohl grundsätzlich richtig; welchen Umfang dies tatsächlich hatte und inwieweit das die Benutzer spürbar gegenüber der offenen Verbindung benachteiligt hatte, ist wohl nicht ermittelt worden.
• Früher wurde lediglich ein einzelner gesonderter Server nur für https benutzt. Das hat sich mit der Umstellung Anfang Oktober 2011 verbessert; im Idealfall waren beide Zugangswege gleichartig und nutzten intern die identische Infrastruktur.
• Die Rechenleistung heutiger PC wie auch der Server ist so stark, dass ein Zusatzaufwand für das Ver- und Entschlüsseln keinen merklichen Anteil an der Gesamtaktivität hat. Die Übertragung verschlüsselter Information über Netzwerke benötigt etwas größere Kapazität; allerdings erfolgt durch die Verschlüsselung gleichzeitig schon eine Datenkompression.
• 2013 sind die sicheren Verbindungen zum Standard geworden; die Server dafür vorbereitet worden.

Weitere Informationen

Meta-Wiki: HTTPS – Allgemeine Informationen (englisch)

Phabricator – Workboard: #https

• Securing access to Wikimedia sites with HTTPS. WikiMedia-Blog, 12. Juni 2015 (englisch)
• HTTPS-Update. In: Wikipedia-Kurier, 21. August 2013.
• Mehr Sicherheit, kaputte Tools, weniger Chinesen. In: Wikipedia-Kurier, 7. August 2013.
• The future of HTTPS on Wikimedia projects. WikiMedia-Blog, 1. August 2013 (englisch)
• secure.wikimedia.org is no more Wikitech Mailing-Liste, 14. November 2012 (englisch)
• Native HTTPS support enabled for all Wikimedia Foundation wikis. WikiMedia-Blog, 3. Oktober 2011 (englisch)