Kurze Zeitreise

Die Geschichte von HTTP beginnt 1989 mit Tim Berners-Lee, einem Physiker am CERN. Er entwickelte das HTTP-Protokoll, um die Übertragung von HTML-Dokumenten, den sogenannten Hypertexten, über das Internet zu ermöglichen. Dies war ein Schlüsselbestandteil seiner Vision vom World Wide Web, einem Informationsmanagement-System, dass es Benutzern ermöglicht, Informationen über das Internet zu teilen und zu verlinken.

Die Veröffentlichung der ersten dokumentierten Version von HTTP, HTTP/0.9, erfolgte 1991. Es war ein sehr einfaches Protokoll, die lediglich die GET-Methode unterstützte. Dies erlaubte einem Webbrowser, eine Anfrage an einen Webserver zu senden und ein HTML-Dokument zurückzuerhalten.

Die Veröffentlichung von HTTP/1.0 erfolgte 1996 als IETF RFC 1945. Es fügte weitere Methoden wie POST und HEAD hinzu und unterstützte auch HTTP-Header, was zusätzliche Metainformationen über die Anfrage und die Antwort ermöglichte.

HTTP/1.1, das heute weit verbreitet ist, kam 1997 zum Einsatz und man hat es später in RFC 2616 festgelegt. Es fügte wichtige Verbesserungen wie Persistente Verbindungen, Chunked-Übertragungen und zusätzliche Cache-Steuerung hinzu.

HTTP/2, im Jahr 2015, mit dem Ziel, die Leistung zu verbessern und die Latenz zu reduzieren. Es unterstützt Multiplexing, Priorisierung und Kompression von HTTP-Headern.

HTTPS – Hypertext Transfer Protocol Secure

Eingeführt, um die Übertragung sensibler Daten über das Internet sicherer zu machen. Es verwendet eine Verschlüsselung, um die Daten vor der Abhörung und Manipulation zu schützen.

Die Geschichte von HTTPS beginnt 1994 mit Netscape Communications, dem Unternehmen hinter dem damals populären Netscape Navigator Webbrowser. Sie führten HTTPS ein, zusammen mit dem SSL (Secure Sockets Layer) Protokoll, um sichere Transaktionen über das Web zu ermöglichen.

Das SSL-Protokoll entwickelte sich über die Jahre weiter und es fand schließlich eine Ersetzung durch das TLS (Transport Layer Security) Protokoll statt, dass man heute für HTTPS verwendet. Die aktuelle Version (Stand Juli 2023) ist TLS 1.3, dessen Veröffentlichung im Jahr 2018 stattfand.

Heute wird HTTPS von fast allen Websites verwendet, die sensible Daten übertragen, wie Online-Banking, E-Commerce und E-Mail-Dienste. Mit der Einführung von Let’s Encrypt, einer kostenlosen, automatisierten und offenen Zertifizierungsstelle, ist HTTPS auch zunehmend auf anderen Websites verbreitet, was zu einem sichereren Web für alle beiträgt. Auch Google achtet auf das Protokoll, wenn man beabsichtigt, das Ranking der Website auf Dauer zu verbessern.

Auch wenn es über die Geschichte ersichtlich ist, wofür unsere beiden Kandidaten gut sind, gehe ich nachfolgend nochmals etwas spezifischer auf die Definitionen, sowie auf die Vor- und Nachteile ein.

HTTP: Was ist das?

HTTP steht für Hypertext Transfer Protocol. Es ist ein Protokoll, das für die Übertragung von Informationen im World Wide Web verwendet wird. HTTP ist zustandslos, das bedeutet, dass jede Anfrage, die über HTTP gesendet wird, unabhängig von den vorherigen Anfragen ist.

HTTPS: Was ist das?

HTTPS steht für Hypertext Transfer Protocol Secure. Wie der Name schon sagt, ist es eine sichere Version von HTTP. Es verwendet SSL (Secure Sockets Layer) oder TLS (Transport Layer Security) Protokolle, um eine verschlüsselte Verbindung zwischen dem Client (zum Beispiel einem Webbrowser) und dem Server herzustellen. Dies bedeutet, dass alle Daten, die zwischen Client und Server übertragen werden, verschlüsselt und daher sicher sind.

Unterschiede zwischen den beiden Protokollen

Der Hauptunterschied zwischen HTTP und HTTPS ist die Sicherheit. HTTP überträgt Daten in Klartext. Das bedeutet, wenn jemand die Daten während der Übertragung abfangen kann, kann er sie leicht lesen und verstehen. HTTPS dagegen verschlüsselt die Daten, die übertragen werden. Das bedeutet, selbst wenn jemand die Daten abfängt, kann er sie nicht lesen, ohne den richtigen Schlüssel zu haben, um die Verschlüsselung zu entschlüsseln.

Ein weiterer Unterschied ist die Port-Nummer, die von den beiden Protokollen verwendet wird. HTTP verwendet Port 80, während HTTPS Port 443 verwendet.

Vorteile von HTTP

Einfachheit: HTTP ist einfacher zu implementieren, da es keine Zertifikate oder Schlüssel benötigt.

Geschwindigkeit: Da es keine Verschlüsselung gibt, ist HTTP in der Regel schneller als HTTPS.

Nachteile von HTTP

Sicherheit: HTTP ist unsicher. Jede übertragene Information, einschließlich sensibler Daten wie Kreditkartennummern und Passwörtern, kann abgefangen und gelesen werden.

Vorteile von HTTPS

Sicherheit: HTTPS ist sicher. Es schützt die übertragenen Daten vor Abhören und Manipulation.

Vertrauen: Websites, die es verwenden, sind in der Regel von Benutzern und Suchmaschinen als vertrauenswürdiger eingestuft.

SEO: Suchmaschinen wie Google bevorzugen HTTPS-Websites und ordnen sie in den Suchergebnissen höher ein.

Nachteile von HTTPS

Komplexität: Die Einrichtung von HTTPS erfordert den Kauf und die Installation eines SSL-Zertifikats. Dies kann für einige Benutzer kompliziert sein.

Leistung: Aufgrund der Verschlüsselung kann es etwas langsamer sein als HTTP.

Fazit

Die Nutzung der beiden Protokolle hängt stark von den Anforderungen und dem Schutzbedarf von Nutzerdaten ab. HTTP, obwohl weniger komplex und in manchen Fällen schneller, bietet keine Sicherheit für übertragene Daten. Jede Information, die über HTTP gesendet wird, ist anfällig für das Abfangen und den Missbrauch.

HTTPS hingegen stellt sicher, dass alle übertragenen Daten verschlüsselt und somit sicher sind. Es bietet ein höheres Maß an Vertrauen für Benutzer und kann sogar die SEO-Positionierung verbessern. Obwohl die Einrichtung der sichereren Variante eine gewisse Komplexität mit sich bringt und die Performance potenziell etwas beeinträchtigt werden kann, sind die Sicherheits- und Vertrauensvorteile in der heutigen digitalen Landschaft unverzichtbar. Aus diesem Grund fällt einem auch immer wieder das Schlosssymbol in der URL Leiste auf, die auf eine ungeschützte oder eben geschützte Website hinweist.

Insgesamt ist es klar, dass der Wechsel zu HTTPS nicht nur für Websites, die sensible Informationen verarbeiten, sondern für alle Websites von Vorteil ist. Dieser Trend zur Universalverschlüsselung ist ein positiver Schritt in Richtung eines sichereren und vertrauenswürdigeren Internets für alle Benutzer und ist in Bezug auf das Kosten-Nutzen-Verhältnis innerhalb eines vertretbaren Rahmens.

Der Beitrag http und https – Eine Reise zur Web-Sicherheit erschien zuerst auf CEOsBay.

Grundlagen von JSON Web Tokens

JWTs sind als offener Standard definiert (RFC 7519) (Siehe Beitrag über RFC und HAL) und sind in vielen Programmiersprachen und Plattformen implementiert. Ein JWT besteht aus drei Teilen: Header, Nutzlast (Payload) und Signatur. Diese Teile sind durch Punkte getrennt und bilden einen kompakten Token, die man beispielsweise in einem https-Header oder einer URL übertragen kann.

Struktur von JWT

Header

Der Header enthält Informationen über den verwendeten Algorithmus zur Signatur des Tokens und den Token-Typ. Typischerweise sieht ein Header folgendermaßen aus:

{
"alg": "HS256",
"typ": "JWT"
}

Nutzlast (Payload)

Die Nutzlast enthält die eigentlichen Informationen, die man zwischen den Parteien austauscht. Diese Informationen bezeichnet man auch als Claims. Der Payload kann sowohl vordefinierte als auch benutzerdefinierte Claims enthalten.

Siehe nachfolgendes Beispiel:

{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}

oder

{
  "user_id": "42"
}

Im zweiten Beispiel ist user_id der Claim-Schlüssel und 42 der zugehörige Wert. Diesen Claim kann man beispielsweise in einem JWT verwenden, um den authentifizierten Benutzer zu identifizieren.

Signatur

Die Signatur dient dazu, die Integrität des Tokens sicherzustellen und zu verhindern, dass man dessen Inhalt manipulieren kann. Dier Erstellung erfolgt durch die Verwendung eines geheimen Schlüssels und des im Header angegebenen Algorithmus (z. B. HMAC-SHA256).

Vorteile von JWT

Stateless und skalierbar

JWTs ermöglichen eine stateless Authentifizierung, da die Nutzlast alle erforderlichen Informationen enthält. Dies bedeutet, dass man keine Sitzungsdaten auf der Serverseite speichern muss. Dadurch sind und bleiben Anwendungen leichter skalierbar.

Einfache Implementierung

Da JWTs auf dem weit verbreiteten JSON-Format basieren, ist ihre Implementierung einfach und sie unterstützt eine Vielzahl von Bibliotheken und Frameworks.

Selbstenthaltend

JWTs enthalten alle erforderlichen Informationen in sich selbst. Dadurch sind keine zusätzlichen Datenbankabfragen zur Verifizierung des Benutzers erforderlich.

Nutzungsszenarien von JWT

Authentifizierung

Man nutzt JWTs häufig zur Authentifizierung von Benutzern in Single-Page-Anwendungen (SPAs) Single Page Applications und APIs.

Autorisierung

Man kann ein JWT auch zur Autorisierung verwenden. Dies lässt sich bewerkstelligen, sofern Informationen über die Rollen und Berechtigungen des Benutzers in den Claims des Tokens enthalten sind.

Informationen teilen

Da JWTs einfach zu erstellen und zu verifizieren sind, kann man sie verwenden, um Informationen zwischen verschiedenen Diensten oder Parteien sicher auszutauschen.

Sicherheitsbedenken und Best Practices

Sichere Übertragung

Man sollte JWTs immer über sichere Kommunikationskanäle wie https übertragen, um Man-in-the-Middle-Angriffe zu verhindern.

Gültigkeit bzw. Ablaufzeit

Tokens sollten eine Gültigkeit bzw. Ablaufzeit (Expiration Time) enthalten, um das Risiko einer Kompromittierung zu minimieren. Sobald ein Token abgelaufen ist, kann man nicht mehr auf die Ressource zugreifen. Dies schafft eine weitere Sicherheitsinstanz, da der Angreifer, selbst wenn er den Zugang gehacked hat, im Besitz des immer wieder neu generierten Tokens sein muss.

Aufbewahrung von geheimen Zugangsdaten

Man sollte den geheimen Schlüssel, den man zur Signatur von JWTs verwendet, sicher aufbewahren und vor unbefugtem Zugriff schützen.

Die Wahl des richtigen Algorithmus

Man sollte einen sicheren Algorithmus für die Signatur von Tokens verwenden. Beispielsweise HMAC-SHA256 oder RSA. Dies, davon ist auszugehen, kann sich mit der fortschreitenden Entwicklung der Quantencomputertechnologie ändern. Folglich ist es immer von enormer Wichtigkeit, die Entwicklungen dahingehend zu beobachten.

Token – Hijacking)

Man sollte darauf achten, dass JWTs nicht im Local Storage oder Session Storage des Browsers gespeichert sind. Dies kann die Seite bzw. Anwendung anfällig für Cross-Site-Scripting-Angriffe (XSS) machen. Daher kann es Sinn machen, https-Only-Cookies zu verwenden.

Fazit

JSON Web Tokens bieten eine moderne, flexible und sichere Methode zur Authentifizierung und Autorisierung von Benutzern in Webanwendungen und APIs. Durch die Stateless-Natur, einfache Implementierung und Selbstenthaltung von JWTs lassen sich skalierbare Lösungen für die Identitätsverwaltung erstellen. Dennoch sollte man sich der Sicherheitsrisiken bewusst sein und Best Practices befolgen, um die Integrität und Sicherheit der Anwendung zu gewährleisten.

Der Beitrag JWT – JSON Web Tokens – Die moderne Authentifizierungsmethode erschien zuerst auf CEOsBay.

Eine kurze Zeitreise

Die Geschichte der RFCs geht auf das Jahr 1969 zurück, als man das ARPANET (Advanced Research Projects Agency Network), den Vorläufer des Internets, ins Leben gerufen hat. Steve Crocker, ein Forscher am ARPANET-Projekt, veröffentlichte das erste RFC-Dokument, RFC 1, am 7. April 1969. Das Ziel war es, eine Plattform zu schaffen, auf der sich Forscher und Entwickler austauschen und Ideen zur Verbesserung und Standardisierung der Kommunikationsprotokolle diskutieren konnten.

Im Laufe der Jahre entwickelte sich das RFC-System zur zentralen Anlaufstelle für die Veröffentlichung und Diskussion von Internetstandards, Protokollen und Best Practices. Die Internet Engineering Task Force (IETF) übernahm die Verantwortung für die Verwaltung und Entwicklung der RFCs, und das RFC-Editor-Team kümmerte sich um die Veröffentlichung und das Format der Dokumente. Übrigens gibt es hier den Link zum RFC Editor mit Index aller RFCs und in HTML 😉

Die Struktur der RFCs

Jedes RFC-Dokument hat eine eindeutige Nummer und einen Titel, der den Inhalt des Dokuments beschreibt. Die Dokumente sind in der Regel in einem einfachen Textformat verfasst, um die Lesbarkeit und den Zugang zu gewährleisten. Eine typische RFC-Struktur umfasst:

• Titel
• Autor(en)
• Datum der Veröffentlichung
• Abstract: Eine Zusammenfassung des Inhalts
• Einleitung: Einführung in das Thema
• Hauptteil: Ausführliche Diskussion und Definition der Standards, Protokolle oder Best Practices
• Referenzen: Liste der verwendeten und zitierten Quellen
• Anhänge (falls erforderlich): Ergänzende Informationen oder BeispieleDie Bedeutung der RFCs

RFCs sind von zentraler Bedeutung für das Internet und seine Funktionsweise. Sie dienen als offizielle Dokumentation für Internetstandards und Kommunikationsprotokolle wie https, SMTP, DNS und viele andere. Darüber hinaus decken RFCs auch Best Practices und Leitlinien für verschiedene Aspekte der Internetkommunikation ab.

Einige wichtige RFCs sind:

• RFC 791: Internet Protocol (IP)
• RFC 793: Transmission Control Protocol (TCP)
• RFC 1034 und RFC 1035: Domain Name System (DNS)
• RFC 2616: Hypertext Transfer Protocol (https/1.1)

Die Veröffentlichung von RFCs erfolgt in einem offenen, transparenten Prozess, bei dem Entwickler, Forscher und Interessierte aus der ganzen Welt teilnehmen können. Dieser kollaborative Ansatz fördert Innovation und ermöglicht es, dass die entwickelten Standards und Protokolle auf breite Zustimmung und Anwendung stoßen.

RFC-Kategorien

RFCs kann man in verschiedene Kategorien eingeteilen:

• Standards-Track RFCs: Diese RFCs definieren offizielle Internetstandards und Protokolle. Sie sind von der IETF entwickelt und genehmigt. Sie durchlaufen einen mehrstufigen Prozess, der von der Entwurfsphase bis zur Verabschiedung als Internetstandard reicht.
• Informational RFCs: Diese RFCs enthalten nützliche Informationen und Ratschläge, die zwar nicht normativ sind, aber dennoch zur Verbesserung der Internetkommunikation und -technologie beitragen können. Beispiele sind Leitlinien, Hintergrundinformationen oder Untersuchungen über neue Technologien.
• Experimental RFCs: Diese RFCs beschreiben experimentelle Ideen oder Protokolle, die noch nicht zur Standardisierung bereit sind. Sie dienen als Plattform, um neue Technologien zu präsentieren und Feedback aus der Community zu sammeln.
• Best Current Practice (BCP) RFCs: Diese RFCs dokumentieren etablierte Verfahren und Leitlinien. Sie sind von der IETF als bewährte Praktiken anerkannt.

Der RFC-Prozess

Der Prozess der Erstellung, Prüfung und Verabschiedung eines RFC ist offen und kollaborativ:

1. Ideenentwicklung: Ein Autor oder eine Gruppe von Autoren erstellt bzw. erstellen einen Entwurf, der die Idee, das Protokoll oder die Best Practice beschreibt.
2. Community-Feedback: Die IETF-Community erhält den Entwurf zur Überprüfung und Diskussion.
3. Überarbeitung und Verbesserung: Überarbeitung und Verbesserung auf Grundlage des erhaltenen Feedbacks, bis dieser für eine formelle Veröffentlichung als RFC bereit ist.
4. IETF-Genehmigung: Für Standards-Track und BCP RFCs ist die Genehmigung der IETF erforderlich, bevor man sie veröffentlichen kann.
5. Veröffentlichung: Nachdem alle notwendigen Schritte abgeschlossen sind, übernimmt das RFC-Editor-Team die Veröffentlichung des Dokuments und das Dokument erhält eine eindeutige RFC-Nummer.

Fazit

RFCs sind ein wesentlicher Bestandteil der Funktionsweise des Internets und der Kommunikation zwischen verschiedenen Systemen und Geräten. Sie stellen eine offene, kollaborative Plattform dar, die es ermöglicht, gemeinsam an der Entwicklung von Internetstandards, Protokollen und Best Practices zu arbeiten. Die Bedeutung der RFCs für das Internet kann man nicht hoch genug schätzen, da sie für die Interoperabilität und Stabilität des gesamten Netzwerks von entscheidender Bedeutung sind.

Der Beitrag RFC – Grundlage für Internetprotokolle und Kommunikationsstandards erschien zuerst auf CEOsBay.

Es handelt sich dabei also nicht um den fast gleichnamigen fiktiven Supercomputer HAL 9000. Den man aus dem Science-Fiction-Roman „2001: Odyssee im Weltraum“ von Arthur C. Clarke oder dem gleichnamigen Film von Stanley Kubrick aus dem Jahr 1968 kennt ;).

Es steht für „Hypertext Application Language“ und basiert auf dem HATEOAS (Hypermedia as the Engine of Application State)-Konzept. Das Ziel von HAL ist es, eine einheitliche Methode zum Beschreiben von APIs bereitzustellen. Gleichzeitig soll sie die Interoperabilität zwischen verschiedenen Systemen und Plattformen verbessern.

Im Wesentlichen besteht ein HAL-Dokument aus zwei Teilen: Ressourcen und Links. Eine Ressource ist eine Datenstruktur, die Informationen über eine bestimmte Entität enthält. Links sind Beziehungen zwischen Ressourcen, die es einem Client ermöglichen, auf eine andere Ressource zuzugreifen. Ein Link enthält normalerweise einen URI (Uniform Resource Identifier). Dieser hat eine eindeutige Adresse für eine Ressource, die sie bereitstellt und einen Relationstyp. Dieser beschreibt, welche Beziehung die verknüpfte Ressource zur aktuellen Ressource hat.

Ein typisches HAL-Dokument ist ein simples JSON [RFC7159] und kann folgendermaßen aussehen:

{
  "_links": {
    "self": { "href": "/api/book/123" },
    "author": { "href": "/api/author/456" }
  },
  "title": "2001: Odyssee im Weltraum",
  "authorName": "Arthur C. Clarke",
  "publishedDate": "1968"
}

In diesem Beispiel enthält das HAL-Dokument eine Ressource, die Informationen über ein Buch enthält, sowie Links zu anderen Ressourcen. Beispielsweise dem Autor des Buches. Der Link mit dem Relationstyp „self“ gibt an, dass der Link auf die aktuelle Ressource verweist. Während der Link mit dem Relationstyp „author“ angibt, dass der Link auf den Autor des Buches verweist.

Ein wichtiger Aspekt des HAL-Formats ist, dass es HATEOAS unterstützt. Dies bedeutet, dass alle Ressourcen in einer API durch Links miteinander verbunden sind. Dadurch kann ein Client einer API eine Ressource abrufen und im Anschluss die verfügbaren Links verwenden, um weitere Aktionen auszuführen. Beispielsweise das Abrufen von verwandten Ressourcen oder das Ausführen von Aktionen auf einer Ressource. Dadurch kann man die Flexibilität und Erweiterbarkeit einer API verbessern. Weil man eben neue Ressourcen und Aktionen hinzufügen kann, ohne dass Änderungen am Client-Code erforderlich sind.

Fazit

Insgesamt ist der HAL-Standard eine nützliche Methode zur Beschreibung von APIs. Es gewährleistet eine gute Interoperabilität zwischen verschiedenen Systemen, steigert die Flexibilität und Erweiterbarkeit einer API.

Der Beitrag HAL-Standard – Effiziente Hypermedia-APIs für nahtlose Web-Service-Interaktionen und erweiterbare Systeme erschien zuerst auf CEOsBay.

Es verfolgt einen dezentralisierten Ansatz, basiert auf den IMAP bzw. SMTP Protokollen und ist, meiner Erfahrung nach, eines der „sichereren“ Messenger Apps, die man heutzutage nutzen kann.

Was ist IMAP?

Das Internet Message Access Protocol (IMAP), ursprünglich Interactive Mail Access Protocol, ist ein Netzwerkprotokoll, dass ein Netzwerkdateisystem für E-Mails bereitstellt.

Was ist SMTP?

Das Simple Mail Transfer Protocol (Einfaches E-Mail-Transportprotokoll), gehört zu der Internetprotokollfamilie, dass zum Austausch von E-Mails in Computernetzen dient)

Durch den Einsatz der E-Mail-Protokolle IMAP und SMTP ist Delta Chat mit jedem herkömmlichen E-Mail-Client kompatibel. Seit Veröffentlichung im Februar 2019 verzeichnet die App im Google Play Store über 100.000+ Downloads. Auch ist die App im Apple App Store verfügbar aber auf die Zahlen haben wir leider keinen Zugriff. Nachdem ein Freund mich darum gebeten hat, heute ein bisschen was über Delta Chat 😉

Wie funktioniert Delta Chat?

Wie anfangs angesprochen, werden die IMAP- und SMTP-Protokolle benutzt. Daher kommt das System ohne Registrierung bzw. Erstellung eines Kontos innerhalb des Messengers selbst und ohne eigene Server aus. Auch wird keine Telefonnummer oder der Zugriff auf das Adressbuch benötigt. Man ist bei der Verwendung nicht auf Nutzer beschränkt, die denselben Dienst verwenden. Folglich kann man damit Nutzer erreichen, die andere Chat-Clients verwenden, da das zugrundeliegende Messaging-Protokoll der offene E-Mail-Standard ist. Alles in allem sehr viel versprechend. Doch zu Beginn habe ich „sichereren“ in Anführungszeichen geschrieben. Bewusst 😉

Dies liegt aber weniger an Messenger selbst, sondern an der E-Mail-Infrastruktur bzw. den zugrundeliegenden Protokollen IMAP und SMTP. Darüber aber nachfolgend mehr.

Verschlüsselung

Bei Nachrichteninhalten wird auf Ende-zu-Ende-Verschlüsselung (E2EE) zur „sichereren“ Kommunikation gesetzt. Unter „E2EE“, versteht man die Verschlüsselung übertragener Daten, über alle Übertragungsstationen hinweg. Nur die Kommunikationspartner (Die jeweiligen Endpunkte der Kommunikation) können die Nachrichten entschlüsseln. Dazu nutzt der Messenger OpenPGP (Ein standardisiertes Datenformat für verschlüsselte und digital signierte Daten). Zertifikate definieren das Format, die als „Schlüssel“ bezeichnet werden. Autocrypt stellt eine weitere Schutzebene dar. Diese Verschlüsselung baut auf dem OpenPGP-Standard auf und ist damit kompatibel. Autocrypt ist ebenfalls eine standardisierte Richtlinie, die eine nutzerfreundliche Verschlüsselung von E-Mails und automatisierten, aber ungesicherten Austausch kryptografischer Schlüssel ermöglicht.

Bei der Verknüpfung eines E-Mail-Kontos generiert Delta Chat bei der Ersteinrichtung automatisch ein Schlüsselpaar. Auch der Import von bereits bestehenden Schlüsseln ist möglich. Mittels Autocrypt werden die öffentlichen Schlüssel anschließend zwischen den Teilnehmern ausgetauscht und ermöglichen damit eine E2EE-Kommunikation. Bei Autocrypt kann theoretisch ein nichtwohlgesonnener E-Mail-Provider diese Verschlüsselung kompromittieren, da Autocrypt grundsätzlich jeden Schlüssel akzeptiert. Dies erfolgt über „Opportunistic Security (RFC 7435)“. Dies werde ich zu einem späteren Zeitpunkt thematisieren, da es den Rahmen sprengen würde. Es ist 06:10 Uhr, Sonntag morgen 😀 – Wen es aber interessiert, kann dennoch auf den Link klicken 😉

MiTM

Auf jeden Fall können wir festhalten, dass das Potential erfolgreicher Man-in-the-Middle-Attacken minimiert wird. Bei einem Man-in-the-Middle-Angriff platziert sich der Angreifer logisch oder physisch zwischen dem Opfer und den verwendeten Ressourcen. Der Angreifer ist dadurch in der Lage, die Kommunikation abzufangen, mitzulesen oder zu manipulieren. Delta Chat erweitert den Autocrypt-Standard daher um countermitm – dadurch wird die Wahrscheinlichkeit einer erfolgreichen Man-in-the-Middle-Attacke auf verifizierte Schlüssel bzw. Kontakte minimiert.

Neben dieser „Schwäche“ kommt hinzu, dass OpenPGP keine Perfect Forward Secrecy beherrscht. (PFS – Perfect Forward Secrecy ist eine Methode für den Schlüsselaustausch kryptografischer Verfahren. Es bewerkstelligt, dass eine nachträgliche Entschlüsselung durch Bekanntwerden des Hauptschlüssels erschwert bzw. ausgeschlossen wird. Die Sitzungsschlüssel werden nicht ausgetauscht und sind nicht mehr rekonstruierbar). Die Schutzziele der „glaubhaften“ Abstreitbarkeit und Folgenlosigkeit sind daher nicht umsetzbar. Um sicher zu stellen, dass man mit seinem wahren Gegenüber kommuniziert, stellt Delta Chat eine Authentifizierung via QR-Code zur Verfügung. Dadurch wird gewährleistet, dass sich kein Dritter zwischenschaltet. Nach der Durchführung des gegenseitigen Scans des QR-Codes, werden die Nutzer als „Verifiziert“ markiert.

Wenn die Empfänger einer Nachricht auch Delta Chat nutzen, werden die Nachrichten automatisch Ende-zu-Ende-verschlüsselt und als Chatnachricht dargestellt. Allerdings erlaubt Delta Chat das Versenden von Nachrichten auch an E-Mail-Postfächer bzw. Kontakte, die kein Delta Chat verwenden. Wenn der Empfänger einen E-Mail-Client verwendet, der nicht Autocrypt-kompatibel ist, werden Nachrichten unverschlüsselt bzw. nur transportverschlüsselt gesendet bzw. empfangen. Das hat den Nachteil, dass ein E-Mail-Provider die so empfangenen / versendeten Nachrichten unter Umständen einsehen kann. Diesen Umstand sollte man unbedingt berücksichtigen bzw. bei der Nutzung von Delta Chat im Hinterkopf behalten. Welche Transportverschlüsselung zum Einsatz kommt, kann in der App eingesehen werden bzw. wird dies im Nachrichtenverlauf mit einem Schloss symbolisiert.

Dezentralisierung

Wie bereits angesprochen, verfolgt Delta Chat den Ansatz der dezentralisierten Kommunikation, da der Nachrichtenaustausch nicht über zentrale Server läuft. Delta Chat setzt auf die bestehende E-Mail-Infrastruktur auf und kann dadurch auf eigene Server verzichten. Die Nutzung von Delta Chat setzt demnach lediglich ein bestehendes E-Mail-Postfach voraus, das mit Delta Chat verknüpft werden muss. Der Nutzer ist also vollkommen frei in seiner Entscheidung, bei welchem E-Mail-Anbieter er ein Konto eröffnet. Die einzige Voraussetzung ist das IMAP-Protokoll.

Fazit

Ist man im Besitz einer E-Mail-Adresse, kann man Delta Chat ohne eine Registrierung und vor allem Serverunabhängig nutzen. Wird Delta Chat von der Gegenseite nicht genutzt, werden Nachrichten an die konventionelle E-Mail-Adresse des Empfängers gesendet. Wenn der Empfänger auch Delta Chat nutzt, bekommt man die Nachricht innerhalb der App angezeigt. Durch diesen Ansatz ist es nicht notwendig, denselben Messenger zu nutzen. Man kann Delta Chat daher auch als interoperablen Messenger nutzen.

Im Grunde genommen eignet sich Delta Chat für Personen, die ihre Telefonnummer nicht teilen wollen. Gleichzeitig kann man sich die Möglichkeit offen halten, über einen Messenger erreichbar zu sein.

Leider ist nicht sichergestellt, dass Nachrichten E2EE verschlüsselt zugestellt werden und damit für einen Angreifer einsehbar sind. Über die Metadaten können die An- und CC-Felder des E-Mail-Headers eingesehen werden. So lässt es sich relativ einfach herausfinden, wer mit wem, zu welchem Zeitpunkt kommuniziert hat. Die Interoperabilität hat durchaus seine Vorteile. Ob die Vorteile dabei die Nachteile überwiegen, darf jeder für sich selbst entscheiden. Alles in allem stellt Delta Chat eine gute Alternative als Instant Messenger dar. Selbst für meinen Geschmack, wird eine gute Portion an Mehrwert für den Dezentralisierungsgedanken leistet.

Der Beitrag Delta Chat – E-Mail neu erfunden erschien zuerst auf CEOsBay.