Web

Web-Übersicht

Bevor wir in den einzelnen Unter-Seiten die Web-Technologien an sich besprechen möchten wir hier eine kurze Übersicht dazu geben, warum diese Technologien existieren, welche Aufgabe Sie in der Kommunikation im Internet erfüllen und wie die verschiedenen Technologien zusammen spielen.

Zur Veranschaulichung werden wir hier zunächst den Aufruf einer typischen Website durchspielen. Als Beispiel verwenden wir die Webseite dieser Dokumentation

Zunächst wird hier ein sog. Web-Browser oder auch nur Browser gestartet.

Bekannte Web-Browser sind Google Chrome, Mozilla Firefox, Microsoft Edge oder sein Vorgänger Microsoft Internet Explorer oder Apple Safari.

Im oberen Teil des Fensters befindet sich in allen genannten Web-Browsern ein langes, einzeiliges Text-Eingabe-Feld. Dies wird als Adresszeile bezeichnet. Rechts daneben findet sich manchmal noch ein weiteres Eingabefeld zur Suche.

Eine Webseite wird immer über eine sogenannte URL addressiert. Diese kann in die Addresszeile eingegeben werden um die Webseite aufzurufen. Alternativ kann auf einen Link geklickt werden der die URL enthält.

Wird nur ein Teil der URL eingegeben, beispielsweise nur „info.saltation.de“, werden fehlende Teile automatisch ergänzt. Dies passiert selbst dann, wenn das Ergebnis nicht eindeutig bestimmbar ist. Im obigen Beispiel könnte die URL entweder

oder

sein. Theoretisch ist es möglich, dass beide Seiten komplett verschiedene Inhalte ausliefern. In der Praxis kommt dies jedoch selten vor. Allerdings ist die Variante mit https:// vorne verschlüsselt während die Variante mit http:// Daten im Klartext überträgt. Daher sollte man https:// vorziehen.

Einige der Browser, insbesondere Google Chrome, verstecken Teile der URL in der Anzeige um Platz zu sparen, funktionieren ansonsten aber wie beschrieben.

Als nächstes muss der Browser feststellen was die URL bedeutet, dazu wird sie in ihre Bestandteile zerlegt:

Der Teil vor dem Doppelpunkt wird als Protokoll oder auch Scheme bezeichnet. Dieser zeigt wie Adresse zu verarbeiten ist. Weitere Details dazu später in der Beschreibung.

Einige Protokoll-Bezeichnungen teilen dem Browser auch mit, dass diese Adresse mit einem externen Programm aufzurufen ist, beispielsweise mail: URLs mit einem Email-Programm. Wir konzentrieren uns hier aber auf URLs mit http und https als Protokolle. Diese werden von Webseiten verwendet.

Der nächste Teil der URL, nach dem doppelten Schrägstrich, wird als Domain- oder Hostname bezeichnet. Dieser Teil ist eine Beschreibung des Servers, der für das Ausliefern dieser Webseite zuständig ist. Man spricht davon dass die Webseite auf diesem Server gehosted ist.

Bei großen Webseiten kann es sich hier natürlich auch um mehr als einen Server handeln. Wir beschränken uns für das Beispiel hier allerdings auf Webseiten die nur einen Server verwenden.

Umgekehrt ist es natürlich ebenfalls möglich, dass auf einem Server mehr als eine Webseite liegt. Der Server ist dann unter mehreren Namen erreichbar.

Der Name ist hierarchisch aufgebaut, die einzelnen Komponenten sind durch Punkte getrennt und die oberste Hierarchie-Ebene ist ganz rechts.

Hinter dem Hostnamen kann optional ein Doppelpunkt mit einer Zahl folgen. Diese Komponente wird als Port bezeichnet, sie wird jedoch meistens weggelassen und der Standard-Port für das verwendete Protokoll wird verwendet, bei http ist dies Port 80, bei https Port 443.

ist also äquivalent zu

und

ist äquivalent zu

Danach beginnt die nächste Komponente immer mit einem Schrägstrich. Dies ist der Pfad innerhalb der Webseite. Es existieren auch noch weitere Komponenten, sog. Query-Parameter beginnend mit einem Fragezeichen und Anchor mit einer Raute.

Auf diese wollen wir hier jedoch nicht näher eingehen. Pfad, Query-Parameter werden vom Server verarbeitet. Der Anchor-Teil wird, zumindest auf einfachen Webseiten, für der Sprung zu Stellen in einem Dokument verwendet.

Zurück zu unserem Browser. Der nächste Schritt ist nun, die Adresse des genannten Servers heraus zu finden.

Die eigentliche Kommunikation im Internet funktioniert nicht mit Namen sondern mit IP-Adressen. Hiervon gibt es aktuell zwei Varianten die parallel betrieben werden. IP Version 4 und 6 (IPv4 und IPv6).

Der Hintergrund hier ist, dass IPv4 insgesamt nur 4 Milliarden Adressen ermöglicht und diese auch nicht alle nutzbar sind. Daher wurde vor einiger Zeit IPv6 entwickelt welches vier mal so lange Adressen verwendet und damit recht zukunfssicher ist.

Die IPv4 Adresse des Servers auf dem info.saltation.de aktuell gehosted ist lautet

94.130.58.15

während seine IPv6 Adresse

2a01:4f8:c0c:247f::2

ist.

IPv4 Adressen bestehen aus 4 durch Punkte getrennten Dezimal-Zahlen die jeweils Werte von 0 bis 255 haben können.

IPv6 Addressen dagegen bestehen aus 8 Abschnitten die durch Doppelpunkte getrennt sind. Jeder Abschnitt besteht dabei aus bis zu 4 Hexadezimal-Ziffern (Zahlenbasis 16, Ziffern 0-9 und a-f repräsentieren 10-15).

In jedem Abschnitt können führende Nullen weg gelassen werden (bis auf die ggf. letzte verbleibende). Außerdem ist es möglich an einer Stelle in einer Addresse beliebig viele Abschnitte die nur aus Nullen bestehen durch zwei Doppelpunkte zu ersetzen. Die obige Adresse ist also voll ausgeschrieben

2a01:04f8:0c0c:247f:0000:0000:000:0002

Diese Schreibweise wird in der Praxis aber normalerweise nicht verwendet.

Überlicherweise wird auf einem modernen System mit beiden Address-Typen zunächst IPv6 versucht und danach IPv4. Dadurch wird bevorzugt das neue System verwendet, wenn ein Beteiligter an der Kommunikation noch keine IPv6-Addresse hat klappt die Kommunikation dann aber trotzdem. Systeme ohne IPv4 Addresse sind möglich, aber noch nicht besonders weit verbreitet.

Wie findet der Browser nun heraus welche IPv4 und IPv6 Adresse zu einem gegebenen Host- bzw. Domain-Namen gehört? Die Antwort auf diese Frage ist DNS, das Domain Name System. Dies ermöglicht die Auflösung von Namen zu Addressen und auch anderen kurzen Informationen.

Aktuell wird DNS weitestgehend ohne Kryptographische Komponenten eingesetzt, es gibt allerdings eine Erweiterung, DNSSEC, die kryptographisch garantieren soll dass man auch korrekte Antworten erhält. Da dies noch nicht sehr weit verbreitet ist möchten wir hier nicht näher darauf eingehen. Bei Fragen zum Thema können Sie sich aber gern direkt an uns wenden.

DNS hat verschiedene Eintragstypen, IPv4 Adressen werden in A-Eintragen gespeichert (A für Adresse). IPv6 Adressen in AAAA-Einträgen (da die Adressen viermal so lang sind wie IPv4 Adressen). Ein weiterer wichtiger Eintragstyp ist CNAME, dies ist im Grunde ein Verweis von einem Namen auf einen anderen.

Es gibt auch noch PTR-Einträge welche die umgekehrte Zuordnung von Adresse zu Name ermöglichen (Reverse DNS-Einträge), MX-Einträge welche den Mailserver für eingehende Mail speichern und viele weitere die weniger häufig zum Einsatz kommen.

Wir erinnern uns, dass der Browser wissen möchte welche IPv4 und IPv6 Addressen zum Server

info.saltation.de

gehören.

Dafür fragt er dann bei einem sog. Recursive DNS Server nach dieser Information.

Die Anfrage ist sinngemäss etwa „Gib mir den AAAA-Eintrag von info.saltation.de“.

Der Server antwortet dann darauf entweder direkt mit dem AAAA-Eintrag von info.saltation.de, mit der Information dass info.saltation.de ein CNAME ist und man bei diesem weiter fragen soll oder mit der Information dass es die Domain nicht gibt.

In unserem Fall kommt die Information zurück, dass info.saltation.de ein CNAME für hetzner10.saltation.de ist. Außerdem schickt der Recursive DNS Server auch gleich die Information zurück dass der AAAA-Eintrag von hetzner10.saltation.de den Wert 2a01:4f8:c0c:247f::2 hat.

Woher hat der Recursive DNS Server diese Information? Er sammelt Sie von den sog. Authoritative DNS Servern für die jeweiligen Domain-Komponenten. Zunächst fragt er bei den sog. Root DNS Server nach welche DNS-Server für de zuständig sind, dort fragt er dann wer für saltation.de zuständig ist und dort bekommt er dann die Antwort über info.saltation.de und in einer zweiten Anfrage auch die Information zu hetzner10.saltation.de.

Die Domain-Hierarchie wird also von rechts nach links aufgewickelt und jede Ebene weiss entweder direkt die Antwort zu den Subdomains unterhalb einer Domain oder sie weiss welcher andere Server für diese Ebene zuständig ist.

Die Root-Server haben generell bekannte IP-Adressen die sich sehr selten ändern.

Natürlich dauert diese Anfrage bei mehreren Server einige Zeit, selbst wenn es sich dabei nur um jeweils einige Millisekunden handelt. Daher möchte man diesen Prozess nicht ständig wiederholen. Daher hat DNS noch einen weiteren Mechanismus um dies zu reduzieren.

Jeder Eintrag hat einen sog. Time-to-live (TTL) Wert und jede Domain hat auch einen TTL-Wert der für Aussagen zur Nicht-Existenz von Einträgen gilt. Dieser Wert wird üblicherweise in Sekunden angegeben.

Er gibt an wie lange ein DNS-Server eine einmal erhaltene Antwort weiterverwenden kann ohne sie neu anzufragen. Der Nachteil ist dass Änderungen im DNS eine Weile brauchen (abhängig vom alten TTL-Wert) bis sie sich verbreiten. Der Vorteil ist, dass Antworten schneller zurück gegeben werden können und die Last auf DNS Servern deutlich reduziert wird.

Da sich viele Einträge im DNS über Jahre nicht ändern ist es normalerweise auch kein Problem wenn diese bei einer Änderung etwas Zeit benötigen. Ein übliches Vorgehen ist, den TTL-Wert eines Eintrags einfach einige Zeit vor einer Umstellung zu reduzieren, dann die Änderung durchzuführen die sich durch die kurze TTL schnell verbreitet und den TTL-Wert danach wieder zu erhöhen wenn sicher ist dass alle Werte korrekt sind.

Zurück zum Aufruf unserer Webseite. Unser Browser hat nun also den AAAA-Eintrag des Webservers erhalten.

Damit kann er dann versuchen, eine Verbindung aufzubauen. Wir gehen hier davon aus, dass wir die URL

verwenden. Der Browser weiss also, dass er https verwenden soll und sich daher auf Port 443 verbinden soll.

Was heisst Port 443? Die IP-Protokolle, über die wir bisher geredet haben, kennen keine Ports. Sie wissen nur, wie man ein Daten-Paket von Adresse A zu Adresse B schickt. Geht das Paket unterwegs verloren, ist das dem IP-Protokoll egal. Wer genau das Paket auf dem Zielrechner erhält ist dem IP-Protokoll egal. In welcher Reihenfolge Pakete ankommen spielt für IP keine Rolle.

Wir benötigen also eine weitere Kommunikations-Schicht die auf IP aufsetzt. Hier gibt es im wesentlichen zwei Protokolle, UDP und TCP. UDP wird für Echtzeitkommunikation wie z.B. Sprache verwendet wo es wichtiger ist dass das aktuelle Paket ankommt als dass vergangene Pakete nachgereicht werden.

Für Kommunikation mit Webservern dagegen wird TCP verwendet. Dies stellt eine Abstraktion eines Datenkanals bereit, Pakete die unterwegs verloren gehen werden erneut gesendet, Paket-Reihenfolgen werden beachtet.

Sowohl UDP als auch TCP verwenden ein Port-Konzept um mehrere Anwendungen auf einem Rechner adressieren zu können. Beide verwenden Ports zwischen 1 und 65535 (jeweils inklusive).

Wie gesagt verwendet die https Kommunikation TCP-Port 443.

Das https Protokoll ist inhaltlich im Grunde identisch zum http Protokoll bis auf die Tatsache dass hier eine zusätzliche Kommunikations-Schicht eingezogen wird welche die http Kommunikation verschlüsselt.

Früher wurde für diese Verschlüsselung das SSL-Protokoll in verschiedenen Versionen (bis 3) verwendet. Die SSL-Protokolle habe alle schwerwiegende bekannte Sicherheitslücken und werden nicht mehr eingesetzt. Aktuell verwenden wir statt dessen TLS welches in Versionen 1.0, 1.1, 1.2 und 1.3 existiert. 1.3 ist aktuell (September 2018) noch sehr neu und wird noch nicht von genug Systemen unterstützt um es exklusiv einzusetzen. TLS 1.0 und 1.1 haben bekannte Sicherheitslücken. Ihr Einsatz sollte, wenn möglich, vermieden werden. TLS 1.2 ist also die aktuell am meisten verwendete Version und ist auch bereits seit einigen Jahren verfügbar. Der Begriff SSL wird häufig noch verwendet, gemeint ist aber heute immer TLS.

Egal ob SSL oder TLS, alle verwenden TCP-Port 443 für die https Kommunikation und Browser und Web-Server kümmern sich um die Aushandlung der besten Version die beide verstehen.

Ein Teil des SSL/TLS Verbindungsaufbaus ist, dass der Server über ein sog. Zertifikat nachweisen muss, dass er tatsächlich ist, wer er vorgibt zu sein.

Dies ist vor allem auf Webseiten wichtig wo Daten wie Passwörter, Bezahldaten oder andere Daten die nicht für jederman bestimmt sind eingegeben werden.

Es ist auch nicht möglich, https oder TLS allgemein ohne ein Zertifikat zu verwenden. Es ist möglich, dass auch der Server vom Client ein Zertifikat verlangt um seine Identität nachzuweisen. Diese Möglichkeit wird aber bei https eher selten verwendet.

Wie funktioniert so ein Zertifikat und woher bekommt man es?

Technisch gesehen handelt es sich hierbei um ein System was auf assymetrischer Kryptographie basiert, in diesem Fall auf dem RSA-Algorithmus. Auf dem Server liegt ein privater RSA-Schlüssel dessen Besitz im Rahmen des SSL/TLS-Verbindungsaufbau nachgewiesen wird. Außerdem liefert der Server ein Zertifikat aus welches die Verbindung zwischen der Domain die der Browser anfragt und den öffentlichen Teil des selben RSA-Schlüssels zertifiziert.

Zertifikate werden über eine sog. Public Key Infrastructure (PKI) vergeben. Sog. Certificate Authorities (CAs) unterschreiben mit ihrem eigenen privaten Schlüssel kryptographisch die Aussage dass der öffentliche Schlüssel zu der Domain gehört und ggf. welcher Organisation die Webseite gehört. Auch weitere Informationen die die Prüfung eines Zertifikats auf Widerruf ermöglichen werden beigelegt.

Browser liefern in der Regel Zertifikate mit aus die bestätigen dass die privaten Schlüssel der CAs tatsächlich vertrauenswürdigen CAs gehören.

Es ist auch üblich, dass in dieser Kette von Zertifikaten noch ein oder mehrere Zertifikate zwischen dem mitgelieferten und dem eigentlichen Webseiten-Zertifikat sitzen. Dies hat den Hintergrund, dass natürlich die CA-Zertifikate in Browsern und Betriebssystemen nicht sehr schnell ersetzt werden können. Daher wird bei den CAs der entsprechende private Schlüssel sicher verwahrt und statt dessen der Schlüssel eines leichter ersetzbaren Zwischen-Zertifikats verwendet.

Wie entscheiden nun die CAs was in ein Zertifikat kommt und welche Zusatz-Informationen zur Organisation dort eingetragen werden?

Hier gibt es mehrere Varianten. Bei einfachen sog. Domain Validation (DV) Zertifikaten muss nur nachgewiesen werden dass man entweder den DNS-Server für die Domain oder den Webserver auf den die Domain aktuell zeigt oder den Mail-Server der aktuell für Mail zuständig ist unter seiner Kontrolle hat.

Dies funktioniert üblicherweise indem eine Datei auf dem Webserver hinterlegt wird, ein DNS-Eintrag vom Typ TXT angelegt wird oder indem eine Mail an eine der bekannten Adressen wie webmaster@, postmaster@,… beantwortet wird.

Bei Organisation Validation (OV) Zertifikaten werden zusätzlich Organisations-Name und -Ort in das Zertifikat eingetragen. Um dies zu prüfen wird zusätzlich zu dem obigen Nachweis noch geprüft ob die Organisation existiert (z.B. Handelsregister-Eintrag) und ob Sie über eine öffentlich verfügbare Nummer (d.h. aus dem Telefonbuch, nicht vom Zertifikat-Antragssteller geliefert) erreichbar ist und bestätigen kann dass dieses Zertifikat angefordert wurde.

Bei Enterprise Validation (EV) Zertifikaten wird außerdem geprüft ob das Zertifikat von der Firmenleitung in Auftrag gegeben wurde. Dies macht z.B. für zentrale Domains von Großkonzernen Sinn denn z.B. nur weil ein einzelner Deutsch Bahn Mitarbeiter das sagt sollte ja nicht gleich ein neues Zertifikat für bahn.de ausgestellt werden.

In jedem Fall benötigt die CA außerdem Informationen über den öffentlichen RSA Schlüssel der verwendet werden soll. Diese Informationen und auch einige andere Vorgaben zum gewünschten Inhalt des Zertifikats finden sich in einer sog. Certificate Signing Request (CSR) Datei. Wir können diese Datei für saltation Kunden auf Anfrage erzeugen. Den Nachweis, dass unser Kunde wirklich ist wer er vorgibt zu sein gegenüber der CA können wir dagegen leider nicht übernehmen.

Bis vor ein paar Jahren war es nur möglich pro IP-Adresse ein Zertifikat zu verwenden. Dies lag daran, dass Browser keine Möglichkeiten hatten, den Server mitzuteilen welche Webseite Sie nach dem TLS-Verbindungsaufbau anfordern werden.

Daher wusste der Server dann nicht welches Zertifikat er dem Browser schicken sollte. Seit einiger Zeit (lang genug dass das inzwischen auch alte Browser unterstützen) gibt es nun die TLS-Erweiterung Server Name Indication (SNI).

Diese rüstet diese Möglichkeit nach und erlaubt es damit heutzutage auch mehr als ein Zertifikat pro IP-Adresse zu verwenden.

Zurück zu unserem Browser. Nachdem der überprüft hat dass der Server wirklich ist wer er vorgibt zu sein steht nun eine verschlüsselte TLS-Verbindung mit dem Server.

Innerhalb dieser TLS-Verbindung kann er nun das http Protokoll verwenden um seine Anfrage an den Server zu stellen. Für dieses Protokoll gibt es wiederum mehrere Versionen, HTTP 0.9, HTTP 1.0 und HTTP 1.0 sowie HTTP 2.0. Auch das Google SPDY Protokoll wird hier von Google Chrome manchmal verwendet. Ich werde im folgenden HTTP 1.1 beschreiben, welches am weitesten verbreitet ist.

Erst hier ist nun die Pfad-Komponente der URL und alles was rechts davon steht relevant.

Die eigentliche HTTP-Anfrage sieht dann für die URL

vereinfacht so aus (einige irrelevante Informationen habe ich weg gelassen):

GET / HTTP/1.1
Host: info.saltation.de
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0

Die Pfad-Komponente aus unserer URL finden wir hier hinter dem GET. Die darauf folgenden Zeilen nennen sich HTTP-Header. Sie liefern Zusatz-Informationen und sind unabhängig von der HTTP-Version erweiterbar.

Der Host-Header hat eine besondere Bedeutung. Er teilt dem Server mit, welcher Domainname angefragt wird. Da die zugrunde liegende Verbindung ja nur auf IP-Adressen basiert hat der Server diese Information ja (abgesehen von der historisch später hinzugefügten TLS SNI-Erweiterung) nicht vorliegen wenn der Browser sie dem Server nicht mitteilt.

Der User-Agent Header teilt dem Server mit welcher Browser von welchem Betriebssystem sich mit Ihm verbindet. Dies ist im wesentlichen zur statistischen Auswertung interessant. Damit kann sich dann die Entwicklung auf tatsächlich von Besuchern der Webseite verwendete Web-Browser konzentrieren.

Historisch wurde auch manchmal auf Basis des Browsers unterschiedliche Versionen einer Webseite ausgeliefert oder unbekannte Browser wurden gleich ganz abgewiesen. Dies wird heute aber von der überwiegenden Zahl der Webseiten-Betreiber als schlechte Idee angesehen.

Der Server verarbeitet nun diese Anfrage und liefert eine Antwort an den Browser. Auch diese besteht wieder aus Headern und darunter aus der eigentlichen Webseite oder anderen Datei die angefragt wurde.

Der Browser kann bei HTTP 1.1 zeitnah weitere Anfragen über die gleiche Verbindung schicken und muss nicht jedes mal wieder eine neue Verbindung aufbauen. Dies passiert in der Regel für weitere Dateien die von der Webseite benötigt werden, beispielweise Bilder oder Javascript-Dateien.

Hat der Browser alle Komponenten der Webseite erhalten (evtl. beginnt er auch schon vorher), so zeigt er die Webseite an.

Nach einem Klick auf einen Link geht das ganze dann mit der neuen URL wieder von vorne los.

Beim ausfüllen von Formularen verhält es sich ähnlich, allerdings wird hier statt einer GET-Anfrage eine POST-Anfrage gestellt. Diese enthält neben der URL noch Zusatz-Informationen, im Falle von Formularen die Werte der Formular-Felder.

Es gibt natürlich noch viele weitere Mechanismen in http, z.B. Caching, Do-Not-Track, die Aushandlung welche Dateiformate, Sprachen und ähnliches der Browser vom Server akzeptiert und viele weitere. Allerdings möchte ich auf die meisten davon hier nicht eingehen.

Ein Mechanismus der noch für Sie als saltation Kunden relevant ist betrifft die Entscheidung zwischen http und https die ganz zu Anfang beschrieben wurde.

Es gibt seit einiger Zeit einen Anwort-Header namens Strict-Transport-Security in dem eine Webseite festlegen kann, dass sie für eine angegebene Zeitspanne (übliche Werte sind einige Monate oder ein Jahr) nur über https, d.h. nur verschlüsselt angesprochen werden soll. Browser merken sich das dann und verbieten es dem Benutzer, die Webseite per http anzusprechen. Entsprechende Versuche werden automatisch in https konvertiert.

Für Webseiten bei denen unverschlüsselte Anfragen nicht sinnvoll sind, z.B. Webshops, macht es Sinn diese Einstellung auf dem Server zu machen. Allerdings tun wir dies nur nach Rücksprache mit Ihnen, da es keine Möglichkeit gibt, dies im Nachhinein für bestehende Besucher wieder rückgängig zu machen.