Kurze Zeitreise

Bis zum Aufkommen der Microservice-Architekturen wurde Software klassischerweise als Monolith entworfen. Dabei gab es keinerlei interne Schnittstellen, da alle Informationen im Monolithen weitergereicht werden konnten. Dementsprechend konnte man sich im Testing nur auf die Stufen Unittests, Integrationstests und End-to-End-Tests konzentrieren. Mit dem Aufkommen der Microservice-Architekturen existiert nun eine Vielzahl an internen Schnittstellen und damit entsteht die Notwendigkeit, diese zu testen. Die Kommunikation der Services untereinander geschieht dabei nicht zufällig, sondern folgt klar definierten Regeln, den sogenannten Schnittstellen-Contracts.

Was ist Contract Testing?

Wie bereits angesprochen, wurde die korrekte Zusammenarbeit von API und Consumer meist durch Integrationstests sichergestellt. Da diese allerdings eine lauffähige Systemlandschaft benötigen, können Fehler erst relativ spät erkannt werden. Bei der Entwicklung ist es jedoch von Vorteil, das Feedback so früh wie möglich zu erhalten. Hinzu kommt, dass Integrationstests eigentlich zum Prüfen der Fachlichkeit dienen. In heutigen Testlandschaften stellen sie strenggenommen „nur nebenher“ fest, wenn es technische Probleme an der Schnittstelle gibt. Das kann sowohl bedeuten, dass der Aufwand bei der Fehlersuche steigt, weil neben fachlichen Problemen auch technische Ursachen zum Fehlschlag des Tests führen können, als auch der Wartungsaufwand der Tests sich erhöht.

Macht also Sinn, dedizierte Tests zu nutzen, um Fehler an Schnittstellen zu finden. Hier bietet sich Contract Testing, genauer gesagt, Consumer Driven Contract Testing (CDCT) an. Verträge für Softwarekomponenten. Der Zusatz „Consumer Driven“ bedeutet, der Consumer bestimmt den Vertrag (Aus diesem Grund nennt man es auch Consumer Contract) und das sich die API nach dessen Vorgaben richten muss.

Neben Consumer Contracts gibt es die etwas verbreiteteren Provider Contracts wie WSDL-/XML-Schemata von SOAP-APIs oder Werkzeuge wie Swagger im Kontext von REST-Services.

Auch wenn sich die Funktionsweise von Framework zu Framework unterscheidet, bleibt die Idee dahinter gleich. Der Provider erfüllt den vom Consumer definierten Vertrag.

Der Vertrag enthält die API samt Parameter und die erwartete (minimale) Antwort. Dabei kann die Beschreibung der Parameter durch den Einsatz von regulären Ausdrücken beliebig präzise sein. So kann der Consumer erwarten, beim Aufruf der API einen unbestimmten String-Parameter oder einen bestimmten String-Parameter aus einem vordefinierten Set zu übergeben. Der zweite Fall ist äußerst hilfreich, wenn der Provider diesen String-Parameter in einen Enum-Wert übersetzt.

Der Consumer Test mit Pact

Sämtliche Verträge zwischen dem Consumer und dem Provider werden in einer JSON-Datei, auch Pact-Datei genannt, definiert. Der Consumer generiert diese Pact-Datei beim Ausführen seiner Pact-Tests und veröffentlicht sie auf dem Pact-Broker. Bei den Tests handelt es sich um gewöhnliche Unit-Tests und sie basieren auf einem der vielen von Pact unterstützen Test-Frameworks wie JUnit oder Jest. In dem Test ruft der Consumer die zu testende API inklusive Parameter auf. Der Aufruf wird von einem Mock-Provider, der vom Pact-Framework zur Verfügung gestellt wird, entgegengenommen. Der Mock-Provider prüft, ob dieser Aufruf mit dem Aufruf aus dem Vertrag übereinstimmt. Sind keine Abweichungen gefunden, antwortet der Mock-Provider mit der minimalen Antwort, die ebenfalls aus dem Vertrag stammt. Der Consumer empfängt in seinem Test die Antwort und vergleicht sie mit seiner Erwartung. Stimmen sie überein, ist der Test erfolgreich. Auf diesem Weg stellt der Pact-Test sicher, dass der Consumer den Aufruf tätigen und die Antwort verarbeiten kann.

Der Pact-Broker ist ein Webserver, der sowohl vom Consumer als auch vom Provider erreichbar sein muss. Er verwaltet die Verträge, indem er sie versioniert ablegt, sie dem Provider zur Verfügung stellt und die Testergebnisse speichert. Die Art und Weise wie der Consumer die Verträge auf dem Pact-Broker veröffentlicht, ist abhängig von der eingesetzten Programmiersprache der Tests und/oder dem eingesetzten Dependendency-Management. Für Maven beispielsweise gibt es ein spezielles Pact-Plugin, das den publish-Goal anbietet, für JavaScript existiert hingegen eine spezielle Pact-Version mit dem Namen Pact-js.

Der Provider Test

Analog zum Consumer-Test ist der Provider-Test auch ein Unit-Test und wird im Rahmen der restlichen Unit-Tests ausgeführt. Hierbei werden alle Verträge, die der Provider mit seinen Consumern abgeschlossen hat, vom Pact-Broker heruntergeladen. Der Aufruf der APIs erfolgt lokal, sodass ein Aufruf durch den Consumer simuliert wird. Der Provider verarbeitet den Aufruf und generiert seine Antwort, die mit der erwarteten Antwort aus dem Vertrag verglichen wird. Sollten sie gleich sein, hat der Provider den Pact-Test bestanden. Ansonsten gilt der Test als fehlgeschlagen und das Artefakt des Providers kann nicht ordnungsgemäß gebaut werden. Die Ursache für Fehlschläge sind in den meisten Fällen Code-Änderungen am Provider ohne den Consumer entsprechend angepasst zu haben oder die Erwartungshaltung des Consumers ist fehlerhaft. In beiden Fällen wird durch CDCT ein Missstand aufgedeckt, der erst zur Laufzeit bemerkbar gewesen wäre.

Alternativen zu Pact

Natürlich ist Pact nicht das einzige Framework zum Implementieren von CDCT, wenn auch aktuell eines der am weitesten verbreiteten. Neben Pact existieren noch ein paar weitere Möglichkeiten für das vertragsbasierte Testen wie Postman, Spring Cloud Contract Project oder Dredd, auf die ich noch in zukünftigen Beiträgen eingehen werde. Aus diesem Grund erfolgt auch das Fazit erst, wenn ich ein paar Vergleiche aufstellen kann.

Der Beitrag Pact.io – Für die nahtlose Integrationstestautomatisierung durch Contract Tests 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.