Schlagwort-Archive: bitbastelei

BitBastelei #174 – XMPP-Server mit Prosody

BitBastelei #174 - XMPP-Server mit Prosody

(36 MB) 00:15:40

2015-11-15 11:00 🛈

XMPP hatten wir ja schon mal – ein Instant Messaging Dienst wie viele ihn tagtäglich nutzen. Der Vorteil: Das Protokoll ist offen – jeder kann sich seinen Client – für welches Endgerät auch immer – aussuchen, selber welche entwickeln oder gar eigene Server betreiben. Um letzteres soll es dieses mal gehen: Mit Pros?dy lässt sich ein solcher in wenigen Minuten installieren.

XMPP-Logo: copyright (c) 1999 – 2011 by the XMPP Standards Foundation (XSF). https://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/#legal
Prosody-Logo: © https://prosody.im

BitBastelei #173 – Arduino Solar-Monitor

BitBastelei #173 - Arduino Solar-Monitor

(286 MB) 00:34:45

2015-11-08 11:00 🛈

Vor etwas längerer Zeit hatte ich einen USBASP mit ATMega8 zusammen mit diversen Stromsensoren ein Solarmonitoring gerbaut. Bis auf etwas bessere Befestigungen lief das System bisher fehlerfrei, jedoch muss nur für das Monitoring ein Netbook laufen um die Daten per USB anzunehmen und auf den Netzwerkanschluss weiterzuleiten. Da ohnehin eine Erweiterung ansteht machen wir es direkt richtig: Der USBASP wird durch einen deutlich größeren ATMega ersetzt, mit mehr Strom- und Spannungssensoren versorgt und erhält letztendlich eine passende Netzwerkkarte um die Daten ohne Umweg an meinen Server zu senden.

BitBastelei #172 – Oneplus One – Firstlook & Cyanogenmod

BitBastelei #172 - Oneplus One - Firstlook & Cyanogenmod

(359 MB) 00:33:03

2015-11-01 11:00 🛈

Glasbruch und keine Ersatzteile verfügbar? Ein neues Handy muss her. Wie immer Zeigt sich: Perfekt gibt es nicht. Geworden ist es das „Oneplus One“ – ein günstiges Smartphone eines chinesischen Herstellers, welches aktuelle Technik recht vernünftig verpackt.

Inhalt:
00:13 Einleitung
02:30 Unboxing & Firstlook
13:01 Installation von Cyanogenmod
22:50 (Etwas) Innenleben
28:50 Fazit

Weitere Hinweise:
– Das Headset-Problem ist offenbar nur Software, könnte also mit Cyanogenmod bereits behoben sein.
– Es werden (wie auch viele andere Handys) nicht alle in Deutschland zugelassenen LTE-Frequenzen unterstützt – Nutzer des Telefonica-Netzes (ehem. O2/E-Plus) müssen ggf. mit Einschränkungen leben.

Links zum Thema:

Cyanogenmod für Oneplus One:
https://wiki.cyanogenmod.org/w/Bacon_Info

Qi-Mod für Oneplus One:
http://imgur.com/a/jRnN4

BitBastelei #171 – ZFS on Linux

BitBastelei #171 - ZFS on Linux

(41 MB) 00:23:38

2015-10-25 11:00 🛈

ZFS ist ein Speichersystem, welches den Aufbau professioneller Speichersysteme ermöglicht.

02:55 – Inodes
03:43 – Blockgrößen
04:31 – Copy on Write
06:25 – Snapshots
07:25 Transaktionssicherheit bei Backups
18:10 – BTRFS https://www.youtube.com/watch?v=y-yYc4sP9zM

BitBastelei #169 – Hausbus: PCB-Prototyp

BitBastelei #169 - Hausbus: PCB-Prototyp

(218 MB) 00:18:33

2015-10-11 10:00 🛈

Im letzten Video hatte ich es ja schon angekündigt: Die ersten Boards sollen kommen. Tja, nun ist es soweit, also schnell zusammenlöten und schauen, dass alles passt. Selbstverständlich nicht ohne Besuch von Murphy.

BitBastelei #168 – PC aufrüsten: CPU, RAM, Lüfter, Grafikkarte

BitBastelei #168 - PC aufrüsten: CPU, RAM, Lüfter, Grafikkarte

(685 MB) 01:02:26

2015-10-04 10:00 🛈

Mein Rechner hat ist sicher noch nicht Reif für die Müllhalde, aber es lässt sich doch noch einiges rausholen: CPU, RAM, Grafikkarte – alles Bauteile, welche sich schnell und Einfach austauschen lassen. In meinem Fall gib es nichts Neues, sondern lediglich gebrauchte Komponenten, welche etwas mehr Leistung bringen sollten. Der bisherige 4-Kern-Prozessor muss einem 6-Kerner weichen, die 20GB RAM werden auf das CPU-Limit von 24GB ergänzt und die beiden treibertechnisch nur noch notdürftig bedienten GeForce 6600GT aus dem Jahr 2004 weicht einer 8 Jahre neueren GTX660.

Der Wechsel der CPU ging schnell und ohne Probleme. Der selbstgebastelte Lüfter musste jedoch schnell einem „Echten“ weichen. Auch die Grafikkarte bereitete keine nennenswerten Probleme. Der Arbeitsspeicher ist hardwaretechnisch schnell getauscht, bereitete aber den größten Ärger: Durch massivie Kompatibilitätsprobleme fühlte ich mich wie in den 90ern. Am Ende steht aber ein aufgefrischtes System, welches mit wenig Geld für die nächsten Jahre gerüstet sein sollte.

Inhalt:

00:00:00 Unboxing – Good Package, bad package
00:02:51 CPU-Specs
00:08:46 RAM-Specs
00:10:09 Blick auf’s Mainboard
00:12:03 HowTo: RAM austauschen
00:14:54 HowTo: Intel-CPU austauschen
00:22:18 Redneck-Kühler
00:27:34 Fehlersuche: Kein Boot nach Aufrüsten
00:32:34 RAM-Kompatibilitäten: Alles läuft – nur nicht stabil…
00:35:51 Lasttests & Benchmarks – lassen wir das…
00:37:53 Arctic Freezer 13: Einbau & Erster Eindruck
00:46:58 Grafikkartenauswahl
00:53:44 Grafikkarteneinbau
00:54:28 VGA vs. DVI vs. HDMI vs. DisplayPort
00:56:21 Grafiktest

Links zum Thema:
26:05 Lüfter-Pinbelegung im Video Festplattenlüfter-Improvisation
55:40 VGA-Adapter
56:53 KVM-Switch = Umschalter für Tastatur, Maus und Monitor

BitBastelei #167 – U2F mit PlugUp – 2-Faktor-Authentifizierung

BitBastelei #167 - U2F mit PlugUp - 2-Faktor-Authentifizierung

(280 MB) 00:13:00

2015-09-27 10:00 🛈

Anmelden im Netz ist für viele die selbe Methode: Nutzername, Passwort, fertig. Man nutzt also das eigene Wissen um die Anmeldung durchzuführen. Der Nachteil: Passwörter lassen sich kopieren – man kann nicht feststellen, wenn jemand Anders dies in Erfahrung bringt. In einigen Bereichen kommt daher ein so genannter „2nd Faktor“ zum Einsatz: Man nutzt neben dem Wissen um das Passwort auch einen Besitznachweis. Vielen Bekannt ist die Methode von Banken: Neben der PIN wird für Überweisungen vielfach der Besitz der Bankkarte kontrolliert. Leider sind deren Protokolle nicht frei verfügbar, entsprechend kann die Sicherheit nicht (vernünftig) überprüft werden. Auch einige Onlinedienste wie z.B. Google unterstützen ähnliches: Mit deren Handy-App Google Authenticator kann der Besitz des Handys abgefragt werden. Nicht hilfreich wenn man auf dem Handy selbst arbeitet, aber immerhin etwas.

Um dieses Gerätechaos zu beseitigen hat sich vor einigen Jahren die FIDO-Alliance gegründet, welche sich zum Ziel gesetzt hat einen einheitlichen, sicheren Zweitfaktor zu definieren. Ergebnis ist U2F, der Universal 2nd Factor. Hierbei besitzt man ein „Token“, welches per USB und/oder NFC an das jeweilige Endgerät angeschlossen wird. Im Token selbst befindet sich ein privater Schlüssel, mit dem nach Nutzerinteraktion eine Anfrage der Webseite signiert wird. Durch diese Methode kann ein hohes Maß an Sicherheit erreicht werden. Bekanntester Vertreter sind die YubiKeys, welche jedoch nicht unbedingt zu den günstigsten Geräten gehören. Auf der letzten Froscon wurde nun nach einem Vortrag gesponsorte U2F-Token verschenkt. Unter der Haube befindet sich das Gerät „PlugUp„, welches zwischenzeitlich in „HappLink“ umbenannt wurde. Zwar ist die Liste der U2F-kompatiblen Seiten leider überschaubar, aber einen Blick drauf werden kann man allemal.

Testseite: https://demo.yubico.com/u2f

#Based on https://code.google.com/p/chromium/issues/detail?id=427966#c19
SUBSYSTEMS=="usb", ATTRS{idVendor}=="2581", ATTRS{idProduct}=="f1d0", SYMLINK+="plugup", TAG+="uaccess", TAG+="udev-acl", MODE="0664", GROUP="uucp"

Update 2016-06-17: Im Original stand MODE auf 0644 – in dem Fall hätte die Gruppe uucp allerdings keinen Schreibzugriff (und damit keine Authentifikation) auf das Dongle. Korrekt ist 0664.

BitBastelei #166: HTTPS, TLS, RSA, PFS, DHE, ECDHE, WTF. – Ein kurzer Überblick (Part 2)

BitBastelei #166: HTTPS, TLS, RSA, PFS, DHE, ECDHE, WTF. - Ein kurzer Überblick (Part 2)

(67 MB) 00:17:28

2015-09-20 11:00 🛈

Part 1: Warum verschlüsseln, Symmetrisch vs. Asymmetrisch
Part 2: RSA, PFS, DHE, ECDHE und sonstige Innereien

HTTPS dürften die meisten kennen, TLS (früher SSL genannt) vielleicht auch, wie sieht es mit RSA, DHE oder ECDHE aus? Alle Begriffe sind Techniken um Zugriffe auf Webseiten zu gegen unberechtigtes Mitlesen abzusichern.

Warnung wie immer: Alles nur als Überblick – die Erklärungen sind stark vereinfacht, teilweise unvollständig und können Fehler enthalten.

Die Grundlagen wurden bereits in Teil 1 gezeigt, nun schauen wir mal auf die Zahnräder.

RSA

Schauen wir uns den Verbindungsaufbau am Beispiel von RSA nochmal genauer an. Entwickelt wurde dieses Verfahren 1977 von Ron Rivest, Adi Shamir und Leonard Adleman am MIT. An der Stelle einen großen Dank an Vincent Bernat, welcher hier eine sehr anschauliche Erklärung (en) geliefert hat.

tls-rsa

  1. Der Client baut eine Verbindung auf und sendet die höchste unterstützte TLS-Version, eine Zufallszahl, eine Sitzungsnummer, eine Liste der unterstützten Crypto-Algorithmen und ggf. der Name des Zielservers (Stichwort VHosts, SNI).
  2. Der Server antwortet ähnlich – auch er sendet die höchste von ihm unterstützte TLS-Version, eine Zufallszahl, die Sitzungsnummer und eine Liste der von ihm unterstützten Crypto-Algorithmen.
  3. Als Nächstes sendet der Server sein Zertifikat, welches den öffenlichen Schlüssel enthält. Etwas mehr zu dem Thema ist im Post „“Vernünftiges” TLS (SSL/HTTPS/…) mit Apache“ zu finden.
  4. Nun folgt die Info, dass der Server mit seinem Hello fertig ist. Dies ist nötig, da nach dem Zertifikat noch weitere Informationen folgen können, welche eine Erweiterung des TLS-Protokolls ermöglichen.
  5. Der Client erzeugt eine weitere Zufallszahl, das pre-master-secret, und verschlüsselt diese mit dem öffentlichen Schlüssel des Servers. Die erste Nachricht, die theoretisch nicht von dritten mitgelesen werden kann.
  6. Nun werden beide Seiten aktiv und berechnen aus dem pre-master-secret sowie den beiden Zufallszahlen aus den Hello-Nachrichten das master_secret, also das „Passwort“, welches für die Verschlüsselung der Verbindung letztendlich verwendet wird
  7. Zuletzt senden beide Seiten eine Nachricht mit dem neuen Schlüssel und prüfen, ob die Nachricht der Gegenseite fehlerfrei entschlüsselt werden kann. Ist dies der Fall wird auf den ausgehandelten Algorithmus (z.B. AES) gewechselt, welcher deutlich weniger Ressourcen benötigt.

Der Mann in der Mitte

Was erst mal gut klingt hat einen Nachteil: Der eigentliche Schlüssel bleibt gleich. Die Kommunikation ist nur so lange sicher, wie der private Schlüssel des Servers nicht bekannt wird. Liest ein Angreifer die verschlüsselten Daten mit, so kann er mit diesen erst einmal nicht viel anfangen. Bekommt er in der Zukunft jedoch Zugang zum Server bzw. dessen Key – z.B. weil dieser Entsorgt wird und der Angreifer sich die Festplatte schnappt – so kann er mit dem privaten Schlüssel das pre_master_secret wiederherstellen. Hiermit hat er nun alle Daten um den zur Kommunikation gehörenden master_key zu berechnen und so alle verschlüsselten Nachrichten entschlüsseln und die Kommunikation im Nachhinein nachvollziehen zu können.

Perfekte Sicherheit? DHE!

Der Konter der Kryptologen lautet „Perfect Forward Secrecy„. Hierbei wird der private Schlüssel nur noch verwendet um sich zu authentifizieren, also nachzuweisen, dass man mit dem richtigen Server kommuniziert. Der Schlüsseltausch wird auf andere Weise erledigt, klassischerweise mit der „Diffie-Hellman-Methode“ unter Verwendung diskreter Logarithmen – in diesem Fall auch Diffie-Hellman ephemeral (DHE) genannt.

Vorsicht, es folgt Formelwirrwarr – wer es einfacher haben möchte überspringt besser den nächsten Absatz.

Zur Durchführung besitzt der Server neben dem bisherigen Schlüsseln einen weiteren Parametersatz: Die DH-Parameter, welche nicht geheim gehalten werden. Diese bestehen aus einer großen Primzahl (p) sowie einer passenden Primitivwurzel (g). Der Server sucht sich nun eine geheime Zahl (a) und berechnet ga mod p (Ergebnis A). Zwischen Schritt 3 und 4 sendet der Server nun eine weitere Nachricht welche die Zufallszahlen der Hello-Nachrichten, die DH-Parameter und das Ergebnis der letzten Rechnung enthält. Die Nachricht ist mit dem privaten Schlüssel signiert, sodass der Client nachprüfen kann, dass die Nachricht tatsächlich vom gewünschten Server stammt und nicht manipuliert wurde. Der Client selbst erzeugt ebenfalls eine Zufallszahl (b) und führt die selbe Rechnung aus, welches B ergibt. Das Ergebnis wird in Nachricht 5 an den Server gesendet. Zusätzlich berechnet der Client Ab mod p = gab mod p, welches das pre-master-secret darstellt. Der Server selbst rechnet Ba mod p, welches ebenfalls gab mod p – also dem pre-master-secret – ergibt. Wer mitliest kennt nun war p, g, ga mod p und gb> mod p – hieraus das pre-master-secret gab mod p zu berechnen ist wegen des „deskreten Logarithmusproblems“ auf absehbare Zeit hoffentlich nicht möglich.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2015/09/dhe05-300×169.png

Farbpanschen

Zu schwer? Wikipedia hat eine schöne Analogie im Angebot:

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2015/09/Diffie-Hellman_Key_Exchange_de.svg-200×300.png Original schema: A.J. Han Vinck, University of Duisburg-Essen
SVG version: Flugaal
German translation: Chillvie
https://de.wikipedia.org/wiki/Datei:Diffie-Hellman_Key_Exchange_%28de%29.svg

Beide Parteien – der Client (Alice) sowie der Server (Bob) starten mit einer gemeinsamen Farbe. Beide denken sich nun zusätzlich eine geheime Farbe aus. Beide Farben werden nun gemischt und an die jeweilige Gegenstelle gesendet. Diese mischt nun erneut die eigene, geheime Farbe hinzu. Es entsteht auf beiden Seiten wieder eine identische Farbe, welche nie übertragen wurde. Die Sicherheit basiert auf der Annahme, dass das mischen der Farben sehr einfach ist, aus dem gemischten aber wieder die beiden Ursprungsfarben zu erhalten sehr aufwändig ist.

Wo ist der Vorteil gegenüber der vorherigen Lösung? Nunja, das Ergebnis basiert ausschließlich auf den generierten Zufallszahlen, nicht dem privaten Schlüssel des Servers. Da diese Zufallszahlen nicht gespeichert werden ist es nach Abschluss der Verbindung nicht mehr möglich das Verschlüsselungspasswort (master_secret) erneut zu berechnen. Die mitgeschnittenen, verschlüsselten Nachrichten sind also nicht wiederherstellbar und somit wertlos. Ganz umsonst kommt dieser Vorteil jedoch nicht: Die nötigen Rechnungen sind sehr aufwändig – Vincent hat hier beobachtet, dass die Last des Clients um das 20-fache, das des Servers um das 3-fache steigt – für große Serverfarmen ein nicht zu vernachlässigender Kostenfaktor.

…die Sache mit dem „weak DH key“

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2015/09/dhe-weak2-300×169.png

Der ein oder andere wird sie schon gesehen haben: Seit einiger Zeit werfen viele Browser beim Besuch einiger Webseiten seltsame SSL-Fehlermeldungen. „ssl_error_weak_server_ephemeral_dh_key“ heißt es so im Firefox, „Server hat eine schwache kurzlebige Diffie-Hellman öffentlichen Schlüssel“ bzw. „Server has a weak ephemeral Dillie-Heffman public key“ oder ERR_SSL_WEAK_EPHEMERAL_DH_KEY in Chrome und auch Safari hat wohl ähnliche Meldungen. Der Hintergrund: Die oben genannten Parameter bestimmen die Sicherheit – weniger als 1024 Bit sollten die DH-Parameter nicht haben, da hier ein Knacken durchaus möglich ist. Empfohlen wird eine Mindestlänge von 2048 Bit. Durch ein historisches Überbleibsel aus einer Zeit, in der starke Verschlüsselung nicht aus den USA in das Ausland gesendet werden durfte, war es möglich solche Verbindungen zwangsweise auf unter 512 Bit herunterzustufen. Die auch als Logjam bekannte Lücke stellte so eine große Gefahr für verschlüsselte Kommunikation dar. Als Gegenmaßnahme begannen Browser Verbindungen mit weniger als 1024 Bit abzulehnen und die oben genannten Fehler zu zeigen.

Was kann man tun? Nun die sinnvollste Methode wäre den Betreiber zu informieren, dass er unsichere Verschlüsselungsparameter nutzt und bitte seinen Dienst auf ein aktuelles Level umstellen sollte. Ist dies nicht erfolgreich verschafft der Verzicht auf HTTPS meist Abhilfe – wirklich sicher wäre die Verschlüsselung ohnehin nicht. Wer nicht um TLS herum kommt kann auch die DH-basierten Verschlüsselungen im Browser abschalten und ihn so zu älteren Algorithmen zwingen. Im Firefox gelingt dies in about:config – dort nach DHE suchen und die mit dhe_rsa_… beginnenden Zeilen per Doppelklick auf abgeschaltet (false) ändern.

…und das mit den Kurven?

In letzter Zeit hat sich ein weiteres Verfahren zum Schlüsseltausch breit gemacht: Elliptische Kurven. Deutlich komplexer als DHE, aber nach aktuellem glauben auch weniger anfällig. Die Masse der öffentlichen Parameter ist deutlich größer: Statt Primzahl und Primitivwurzel wird nun eine Kurve (y²=x³+ax+b), eine Primzahl (p) und ein Startpunkt (G) benötigt. Da das Erstellen der Kurven extrem aufwändig ist werden diese üblicherweise nicht selbst berechnet, sondern man greift auf eine öffentliche, vorberechnete Kurve wie z.B. P-256, P-384 oder P-521 des amerikanischen National Institute of Standards and Technology (NIST) zurück. Der Schlüsseltausch ist ähnlich zu DHE:

  • Der Server denkt sich eine Zufallszahl (a) aus und berechnet aG, welches in der signiert an den Client gesendet wird.
  • Der Client prüft die Signatur, generiert ebenfalls eine Zufallszahl (b) und sendet bG
  • Beide Seiten berechnen per b·aG bzw. a·bG abG, welches als pre-master-secret genutzt wird

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2015/09/ecdhe11-300×169.png

Wichtig hierbei: Die gezeigten Additionen/Multiplikationen finden auf der Kurve statt und sind nicht mit den Schulrechnungen zu vergleichen. Eine weitere, gute Erklärung in Videoform liefert CSBreakdown. Zur Addition werden die Summanden auf der Kurve markiert, hiervon leitet man eine Linie ab, welche neben den Ursprüngen einen dritten Schnittpunkt ergibt. Dieser wird über die Y-Ache verlängert, der Schnittpunkt am anderen Ende der Kurve stellt das Ergebnis dar.

Rechnen in der Kurve

Zur Addition wird erst eine Punktverdopplung vorgenommen. Hierbei wendet man o.G. Methode an, statt der Summanden ist jedoch der Winkel der Kurve am Punkt (A) der Ursprung. Im Anschluss kann das Ergebnis 2A wieder mit A addiert werden um auf 3A zu kommen, etc.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2015/09/curve06-300×169.png

Da – wie schon Erwähnt – viele der hier verwendeten Daten vorberechnet sind ist der Vorgang weniger rechenintensiv, stellt aber trotzdem die zuvor beschriebene „forward secrecy“ bereit. Im Gegensatz zur „normalen“ Verschlüsselung ist hier bei effizienter Nutzung nur die doppelte Zeit am Client und etwa 15% Mehrleistung am Server zu erwarten.

Alle aktuell im Desktop- und Mobil-Bereich genutzten Browser und Systeme unterstützen diese Methode, wer jedoch exotische Geräte oder veraltete Software (Anderoid <4, Windows XP, etc) nutzt muss auf diesen Weg verzichten.

BitBastelei #166: HTTPS, TLS, RSA, PFS, DHE, ECDHE, WTF. – Ein kurzer Überblick (Part 1)

BitBastelei #166: HTTPS, TLS, RSA, PFS, DHE, ECDHE, WTF. - Ein kurzer Überblick (Part 1)

(26 MB) 00:07:18

2015-09-20 10:00 🛈

Part 1: Warum verschlüsseln, Symmetrisch vs. Asymmetrisch
Part 2: RSA, PFS, DHE, ECDHE und sonstige Innereien

HTTPS dürften die meisten kennen, TLS (früher SSL genannt) vielleicht auch, wie sieht es mit RSA, DHE oder ECDHE aus? Alle Begriffe sind Techniken um Zugriffe auf Webseiten zu gegen unberechtigtes Mitlesen abzusichern.

Warnung wie immer: Alles nur als Überblick – die Erklärungen sind stark vereinfacht, teilweise unvollständig und können Fehler enthalten.

Warum überhaupt?

Ich hab doch nichts zu verbergen!

So heißt es vielfach, wenn man über Verschlüsselung diskutiert. Aber ist das wirklich so? Selbst wenn man selbst sein ganzes Leben zugänglich macht, so gibt es dennoch Gründe nicht alle Daten unverschlüsselt zu übermitteln. Klassisches Beispiel: Zugangsdaten. Werden diese ungeschützt übertragen können sie von Dritten abgefangen werden. Unerwünschte Posts können schnell mit Stress im Freundeskreis oder gar vor Gericht enden. Und das Konto wäre vermutlich ebenso schnell leer. Hätte man die Daten besser mal verborgen.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2015/09/3-mettbook-userpass-300×227.png

Symmetrische Kryptografie

Fangen wir mit dem einfachsten an: Symmetrische Kryptografie. Hierunter versteht man Verfahren, bei denen z.T. ein Text mit einem Passwort verschlüsselt wird. Das Ergebnis ist für Außenstehende nicht zu entziffern und somit wertlos. Wer jedoch den Schlüssel kennt kann aus dem Kauderwelsch wieder den ursprünglichen Text reproduzieren.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2015/09/sym7-300×169.png

Solche Verfahren sind natürlich schön für Dokumente, jedoch Problematisch für Webseiten: Entweder müssten alle Besucher das selbe Kennwort kennen – könnten also auch die Daten der anderen entschlüsseln – oder man müsste für jeden Besucher ein eigenes Passwort aushandeln. Nur wie, wenn der Besucher zum ersten mal die Seite aufruft? Etwas anderes muss her.

Asymmetrische Kryptografie

Klassischerweise wird zum Schlüsseltausch im Internet ein asymmetrisches Verfahren verwendet. Hierbei hat der Betreiber der Webseite einen „Schlüssel“ erstellt, welcher aus zwei Teilen besteht: Einem privaten Teil, welcher geheim gehalten wird, und einem öffentlichen Teil, welcher allen Besuchern weitergegeben wird. Dahinter steckt eine Einwegfunktion – sozusagen eine mathematische Einbahnstraße. Mit dem öffentlichen Teil lässt sich ein Text einfach verschlüsseln, jedoch das Ergebnis nach aktuellem Stand nicht mehr Zurückrechnen. Hat man jedoch den privaten Teil, so hat man auch die fehlenden Informationen um aus dem zuvor berechneten Wirrwarr wieder den ursprünglichen Text zu erhalten. Der Client kann also dem Server verschlüsselte Nachrichten zukommen lassen, ohne die Gefahr des Mitlesens.

Ebenfalls möglich ist eine andere Richtung: Mit dem privaten Schlüssel kann der Server eine Nachricht unterschreiben, also bestätigen, dass diese von ihm so gewollt ist. Der Client kann mit dem öffentlichen Teil am Ende prüfen, ob die Unterschrift tatsächlich vom Absender stammt und der Text unterwegs nicht verändert wurde.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2015/09/asym12-300×169.png

Zertifikatswahn

Wem ist etwas aufgefallen? Wir benötigen öffentliche Schlüssel für alle verschlüsselten Webseiten. Doch wo kommen sie her? Nun – das ist schnell gelöst: Der Server schickt uns diese beim Verbinden. Klingt praktisch, hat aber einen Nachteil: Wir können nicht sicher sein, dass das Ziel tatsächlich unser Server und nicht ein Angreifer zwischendrin ist. Der Lösungsansatz lautet X.509, oder kurz: Zertifikate. Diese Zertifikate enthalten nicht nur den Schlüssel, sondern auch weitere Informationen wie den Servernamen, die zugehörige Organisation, ein Haltbarkeitsdatum und einen Fingerabdruck. Zusätzlich sind diese Zertifikate zum Nachweis der Identität des Betreibers von einer weiteren Firma, der so genannten Certificate Authority (CA) unterschrieben. Alle aktuellen Browser und Betriebssysteme haben eine Liste mit Firmen, welche solche Unterschriften leisten dürfen, im Lieferumfang. Ist das Zertifikat von einer dieser Firmen unterschrieben, so vertraut der Browser diesem ohne weitere Nachfrage. Ist die Unterschrift unbekannt erhält man eine passende Warnung. In diesem Fall kann man natürlich trotzdem z.B. den erhaltenen Fingerabdruck telefonisch mit dem Betreiber abgleichen und so die Identität selbst feststellen.