Schlagwort-Archive: TLS

BitBastelei #290 – MQTT (Protokoll, Mosquitto, ESP8266, HomeAssistant, TLS)

BitBastelei #290 - MQTT (Protokoll, Mosquitto, ESP8266, HomeAssistant, TLS)

(265 MB) 00:38:36

2018-07-01 10:00 🛈

In den letzten Jahren hat sich im Bereich der herstellerübergreifenden Hausautomation MQTT als Protokoll verbreitet. Schauen wir mal wie das Protokoll funktioniert, wie wir selbst einen Server aufsetzen und diesen absichern und letztentlich wie wir mit ESP8266 und HomeAssistant einen eigenen Sensor implementieren können.

Inhalt:

  • 00:00 Das Protokoll
  • 05:17 Installation von Mosquitto
  • 07:52 TLS und Passwörter mit Mosquitto
  • 22:28 MQTT mit HomeAssistant
  • 25:03 MQTT mit ESP8266/Arduino

Links:

  • Anleitung von Auxnet
  • Fingerprint-Befehl: echo | openssl s_client -connect localhost:1883 | openssl x509 -fingerprint -noout

Demo-Quellcode:
https://gist.github.com/adlerweb/807aee4a79a8dee043113d86172e7792
BitBastelei #290 – MQTT (Protokoll, Mosquitto, ESP8266, HomeAssistant, TLS) weiterlesen

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.

Pidgin XMPP mit Selfsigned-Zertifikaten

Huh? Bei einer Neueinrichtung ließ sich Pidgin nicht dazu überzeugen eine Verbindung zu meinem XMPP(/Jabber)-Server herzustellen – SSL fehler. Ursache ist offenbar, dass das verwendete Zertifikat nicht von einer CA signiert wurde, der das System standardmäßig vertraut.

Erste Möglichkeit: Die CA bzw. das selbstsignierte Zertifikat im System importieren. Auf den meisten Systemen sind hierzu jedoch Systemverwalterrechte erforderlich, sodass diese Methode nicht immer machbar ist – also schnell weiter zu…

Zweite Möglichkeit: Per Hand. Hierzu benötigen wir ebenfalls erst mal das Zertifikat. Hat man dies nicht zu Hand kann man sich mit OpenSSL behelfen. Als Client instrutiert wird u.A. das Zertifikat in ASCII ausgegeben:

openssl s_client -host myjabber.server -port 5222  -starttls xmpp

-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----

Dieses Zertifikat – inklusive der BEGIN/END CERTIFICATE-Header – kopiert man in eine Textdatei und speichert sie als *.pem-Datei auf der Festplatte ab. Um dieses Zertifikat nun in Pidgin zu erlauben öffnet man Werkzeuge->Zertifikate und wählt unter hinzufügen die zuvor gespeicherte Datei aus.

Bild: https://adlerweb.info/blog/wp-content/uploads/2015/08/sslpidgin-300×120.png

Nun sollte die Verbindung korrekt funktionieren. Schade, dass hier keine einfachere Nachfrage implementiert wurde, welche beim ersten Verbinden ohne weiteren Eingriff eine Zertifikatsausnahme zulässt.

Spaß mit TLS – 1.0 vs. 1.2

TLS dürfte jedem Internetnutzer bekannt sein – naja, OK, vielleicht nicht unter dem Namen, aber spätestens bei Ablegern wie „HTTPS“ sollte es Klick machen. TLS stellt quasi die Basis der verschlüsselten Kommunikation im Internet dar – Shopping, Onlinebanking, E-Mails & co werden so vor unerwünschten Einblicken geschützt. 1999 wurde die erste Version offiziell spezifiziert, eine Weiterentwicklung der Netscape-Erfindung SSL.

Computertechnik ist nicht gerade dafür bekannt, dass sie sonderlich lange hält, daher ist es kaum verwunderlich, dass der Standard inzwischen mehrmals erneuert wurde. Aktuell ist TLS 1.2 aus dem Jahr 2008, welches u.A. einige Lücken schließt.

Natürlich konnte ich nach dem Hinweis von SemperVideo es nicht lassen mal einen Blick auf diverse Seiten zu werfen. Während viele private Blog und andere Auswüchse des „Social Media“-Bereiches häufig bereits TLS 1.2 im Einsatz haben sieht es bei klassischen Firmen eher mau aus – als Beispiel sei hier der Onlineriese Amazon und die Banken der VR-Gruppe Süd genannt, welche beide lediglich TLS 1.0 anbieten – erstere sogar ohne PFS, welches Angriffe vielfach erleichtert.

Im Falle der Bank konnte ich eine Stellungnahme der GAD erhalten, welche für die Betreuung der technischen Infrastruktur zuständig ist.

Guten Tag,

unsere Sicherheitsstandards werden regelmäßig durch unsere Experten überprüft, verändert und ggf. erneuert. So auch in dem von Ihnen genannten Fall. Eine Aktualisierung ist für das nächste Jahr geplant.

Aussagen der Fachbereiche haben ergeben, dass zwar seit fünf Jahren der Verschlüsselungsstandard TLS 1.2 auf dem Mark ist, aber dass viele Browser und auch Webserver diesen Standard noch nicht unterstützten.

Anbei auch nochmal eine Meldung vom Juli 2013, bez. TLS 1.2 und Browsersupport.

http://www.golem.de/news/tls-1-2-bald-bessere-verschluesselung-fuer-firefox-und-chrome-1307-100370.html

Freundliche Grüße

GAD eG

Prinzipiell verständlich, auch wenn die Aussage, dass der Standard noch nicht unterstützt würde inzwischen großteils überholt ist – zudem ist das System abwärtskompatibel. Wie auch immer: Das Thema scheint beim Dienstleister der Bank bereits bekannt zu sein und der Zeitplan ist für diese Branche bei nicht direkt angreifbaren Sicherheitsupdates relativ zügig – imo angemessene Reaktion, schade, dass man häufig lediglich auf Schweigen oder themenfremde Textblöcke trifft.