## Serverkonfig: **dns:** x.web.de **Dir:** /var/www/x Das **Zert** befindet sich in /certs/x.pem **Key:** /certs/x.key **Loesung:** ``` server { listen 443 ssl; server x.web.de; root /var/www/x; cert /certs/x.pem; key /certs/x.key; } ``` ## Datenpakete skizzieren: **x.web.de:** 2.3.4.5 **Browser:** 4.4.4.5 https://x.web.de/bilder/klasse.html ### Request: ``` Ethernet| Inet | tcp | tls | http | Daten Macs | 4.4.4.5 |2727 | | dns: x.web.de | | 2.3.4.5 |443 | | GET /bilder/klasse.html | (! Client bekommt eine freie Portnr > 1023) ``` ### Response: ``` Ethernet| Inet | tcp | tls | http | Daten Macs | 2.3.4.5 |443 | | Content-Type: html | <html>... | 4.4.4.5 |2727 | | | ``` ## Server auf Webdienst weiterleiten **Server:** y.web.de **Webdienst:** http://localhost:3456 ``` server{ listen 443 ssl; server y.web.de; location / => http://localhost:3456; cert /certs/y.pem; key /certs/y.key; } ``` # Probe Sa Webserver verwenden das Protokoll **http**. Dieses Protokoll ist **zustandslos**. Was bedeutet dies? *Es wird bei jedem Zugriff eine neue Verbindung aufgebaut, der Zustand der alten Verbindung ist unbekannt.* Wie kann eine http-Anwendung einen Zustand bekommen: *SessionId in cookie speichern* Auf Ihrem Webserver besteht eine Zwangsumleitung fuer alle http-Anfragen. Was bedeutet dies? *Jede http Anfrage wird auf https umgeleitet, damit alles verschluesselt ist* Was steht in so einem Zertifikat? *Dns-Name <=> publicKey, TC-Signatur, Gueltigkeitsdauer...* Was ist ein Wildcard-Zertifikat? *Gilt fuer alle Namen in einer (sub)domain* Was ist Wildcard-DNS: *alle SubDomains eines Namens haben im DNS die gleiche Ip. A.b11b.de b.b11b.de,... haben alle die ip 4.5.6.8* Fuer was sind die Wildcard-Teile nuetzlich? *Fuer vHost, revProxys* Handelt es sich bei Ihrem zert um ein Wildcard Zertifikat? *Ja* Erstellen Sie eine Konfig fuer einen vHost. Anfragen an https://x.b11b.de werden aus dem Verzeichnis /www/x beantwortet ``` server { listen 443 ssl; server x.b11b.de; zert /z.b11b.zert; key /z.b11b.key; root /www/x; } ``` Das Programm rest1.exe beantwortet auf Port 6789 Rest-Anfragen Wie koennen Sie erreichen, dass das Prog ueber die URL https://rest1.b11b.de erreichbar ist? ``` server { listen 443 ssl; server rest1.b11b.de; zert /z.b11b.zert; key /z.b11b.key; Location /=> http://localhost:6789/; } ``` Hans hat die Ip 4.5.6.7. Hans gibt im Browser obige Url ein. Skizzieren Sie ein Datenpaket. | Inet | tcp | tsl | Http | Daten | | -------- | -------- | -------- | --- | --- | | 4.5.6.7 | 4569 | (version) | Rest1.b11b.de | | |4.5.6.8|443||GET /| | Skizzieren Sie das Datenpaket der Antwort des Servers | Inet | tcp | tsl | Http | Daten | | -------- | -------- | -------- | --- | --- | | 4.5.6.8 | 443 | (version) | Rest1.b11b.de | {"daten":"???"} | |4.5.6.7|4569||Content-Type: apllication/json| | Was bedeutet SSL-Terminierung? *Der Transport vom Browser zum revProxy wird TLS verschluesselt, der Weg zum rest1-Programm (interner Server) ist unverschluesselt* Hans hat das Prog rest1.exe in ein docker-image hans/rest1 verpackt, starten Sie 2 Container von diese Image: *docker run -d -p 6789:6789 hans/rest1 docker run -d -p 6790:6789 hans/rest1* Hans will jetzt einen Datenschatz ({"titel":"sa2"}) ueber die restApi beim Endpunkt /buch einfuegen Skizzieren Sie das Datenpaket: | Inet | tcp |Http | Daten | | -------- | -------- | -------- | --- | | 4.5.6.7 | 4569 | Rest1.b11b.de | {"titel":"sa2"} | |4.5.6.8|6789|POST /buch| | |||Content-type:application/json| Mit welchem http-Befehl sollte nach dem Rest-Prinzip eine Ressource geaendert werden? *PUT* Eerklaeren SIe die Bestandteile einer Url: *Protokoll: http, ws, imap (optional mit tls) Server/Domain/ServerIp UrlPfad optional user/passwd* http://user:passwd@server/pfad Warum darf ein Javascript in der Webseite http://engel.net nciht mit Rest-Befehlen auf http://engel.rest/kfz zugreifen? *SOP:Javascript darf nur auf Resourcen zugreifen die vom gleichen Server wie die Webseite kommen, ausserdem muessen beide das gleiche Protokoll verwenden http oder https* # Webserver ## Ablauf 1. Der Client gibt im Browser http://www.schule.de/info/klasse.html ein => ein GET Request wird an den Server gesendet 2. Der http-Server holt aus dem DocumentRoot die Datei info/klassen.html und 3. sendet deren Inhalt an den Browser . Der rendert und stellt das htm huebsch dar. | Internet H | Transportschicht H | http Header | Daten | | -------- | -------- | -------- | --- | | 3.3.3.3 | >1023 | www.schule.de | | |4.4.4.4|80|GET /info/klasse.html| ## Begriffe ### Url Aufbau protokoll://dnsName/Urlpfad - protokoll: http, ftp, https - dnsName des Servers (steht im http-Header) - Urlpfad: Pfad zur gewuenschten Datei im Documentroot ### DocumentRoot Verzeichnis in dem der Webserver die Datei des Urlpfades sucht ## Virual Host (vHost) Ein Server mit 1 offiziellen iP und vielen dns-Namen, kann pro dns-Name einen virtuellen Host einrichten. Dies ist die Zuordnung DNS-Name => DocumentRoot. D.h. je nach dns-Name werden die html-Name werden die html-Dateien aus einem anderen DocumentRoot geholt. Bzw. je nach dns-Name sieht der Client einen anderen Webserver. | Internet H | Transportschicht H | http Header | Daten | | -------- | -------- | -------- | --- | | 3.3.3.3 | >1023 | www.schule.de | | |4.4.4.4|80|POST /save.php| |||Content-type: application/json| | Internet H | Transportschicht H | http Header | Daten | | -------- | -------- | -------- | --- | | 3.3.3.3 | 80 | Content-type: application/json | "{'status':'ok'}" | |4.4.4.4| >1023|| ## Reverse Proxy - beliebige Programme, die ueber das http-Protokoll ansprechbar sind ueber https erreichbar machen - die Progs funktionieren meist nach dem Rest-prinzip - die Progs sind ueber 127.0.0.1:???? erreichbar - sinnvoll: Wildcard-Dns: z.B. ?.x.dvs.de zeigt auf die IP 1.2.3.4 - pro Prog wird ein dnsname zu dessen Port weitergeleitet - statt dem root-Eintrag: proxy-Direktiven # Rest kein Protokoll, sondern ein Prinzip: Eine Resource wird durch eine Url dargestellt. Durch einen Endpunkt wird eine Resource angesprochen: https://server/Endpunkt ## Datenpakete ![image](https://hackmd.io/_uploads/HyJ-euMZR.png) # Auth Webanwendungen ## Token **Bearer-Token** = Inhaber - Token => der Inhaber des Tokens - auch ein Dieb - ist authentifiziert. Entweder enthaelt der Token keine weiteren Infor oder es wird ein JWT verwendet **JWT** Json Web Token. Dieser enthaelt - vom Server signierte - Infos (Name, Gruppe, Gewicht, ...) **Hardware Token**: smardcard, fido2 usb-stick, PIN-Generator ![image](https://hackmd.io/_uploads/r14a-ufWC.png) ![image](https://hackmd.io/_uploads/ByRTW_MWA.png) ![image](https://hackmd.io/_uploads/HkyyzOG-A.png) **SAML:** - SAML steht für Security Assertion Markup Language. - Es ist ein XML-basiertes Protokoll. - Ermöglicht sicheres Austauschen von Authentifizierungs- und Autorisierungsinformationen. - Benutzer können sich einmal anmelden und ihre Identität sicher mit anderen Websites oder Diensten teilen. **oauth2:** - OAuth 2.0 ist ein Autorisierungsprotokoll. - Es ermöglicht Benutzern, Drittanwendungen Zugriff auf ihre geschützten Ressourcen zu gewähren. - Benutzer müssen ihre Anmeldeinformationen nicht direkt an die Drittanwendung weitergeben. - OAuth 2.0 bietet einen sicheren und standardisierten Weg für die Autorisierung und den Zugriff auf Ressourcen über das Web. ![image](https://hackmd.io/_uploads/rkDyMOGbA.png) **oidc:** - OpenID Connect (OIDC) ist eine Authentifizierungs-Protokoll. - Es baut auf OAuth 2.0 auf und erweitert es um Identitätsinformationen. - OIDC ermöglicht es Benutzern, sich sicher bei verschiedenen Diensten anzumelden, ohne bei jedem Dienst separate Anmeldeinformationen verwenden zu müssen. - Es ermöglicht auch die sichere Übertragung von Benutzeridentitätsinformationen zwischen verschiedenen Anwendungen und Diensten im Internet.