Was ist SSH?

Es ermöglicht die sichere Kommunikation zwischen zwei Systemen über ein unsicheres Netzwerk wie das Internet. Es bietet eine verschlüsselte Sitzungsprotokollierung und Dateiübertragung, wodurch es zu einer idealen Lösung für die Fernadministration von Servern und sicheres Surfen über unsichere Netzwerke wird.

Die Entstehung von SSH

SSH entstand Anfang der 1990er Jahre. Tatu Ylönen, ein Forscher aus Finnland, entwickelte es als Reaktion auf einen Passwort-Sniffing-Angriff auf sein Universitätsnetzwerk. SSH1, die erste Version, erschien 1995 und fand rasch breite Akzeptanz. Um Mängel in SSH1 zu adressieren, entwickelte man SSH2 mit verbesserten Sicherheitsmechanismen. Heute verwenden fast alle modernen Systeme SSH2.

Anwendung von SSH

Es dient mehreren Zwecken:

1. Fernzugriff: Administratoren nutzen es, um sich sicher mit einem Remote-Server zu verbinden und Befehle auszuführen.
2. Dateiübertragung: Mit SCP (Secure Copy Protocol) und SFTP (Secure File Transfer Protocol) lassen sich Dateien verschlüsselt übertragen.
3. Port-Weiterleitung: Man kann lokale und entfernte Ports weiterleiten und so sichere verschlüsselte Tunnel für andere Anwendungen bereitstellen.

Beispiel: Verbindung zu einem Remote-Server:

ssh benutzername@serveradresse

Einrichtung

Um es nutzen zu können, installiert man den OpenSSH-Server und -Client. Viele moderne Betriebssysteme, wie Linux-Distributionen und macOS, liefern bereits vorinstallierte Tools.

Beispiel: Installation von OpenSSH unter Ubuntu:

sudo apt update sudo apt install openssh-server

Nach der Installation startet der Dienst automatisch. Man kann den Status mit folgendem Befehl prüfen:

sudo systemctl status ssh

Zur Sicherheit sollte man einige Einstellungen in der Konfigurationsdatei anpassen:

1. Port ändern: Den Standardport 22 ändern, um Basisangriffe zu vermeiden.
2. Root-Login verbieten: Den Root-Zugriff über SSH deaktivieren.
3. Zugriff einschränken: Nur bestimmten Benutzern den Zugriff erlauben.

Diese Änderungen nimmt man in der Datei /etc/ssh/sshd_config vor und startet anschließend den SSH-Dienst neu.

Abschließend sollte man sich immer um regelmäßige Sicherheitsupdates kümmern, um das System und SSH gegen bekannte Schwachstellen abzusichern.

Fazit

SSH hat sich seit seiner Entstehung als ein unverzichtbares Tool für sichere Kommunikation im Netz etabliert. Mit dem richtigen Know-how und einigen Sicherheitsvorkehrungen bietet es eine robuste und sichere Methode für die Fernadministration und Dateiübertragung.

Der Beitrag SSH (Secure Shell) – Sichere Kommunikation, jederzeit und überall erschien zuerst auf CEOsBay.

Geschichte der URL

Die Geschichte ist untrennbar mit der des Internets verbunden. Tim Berners-Lee, ein britischer Informatiker, entwickelte Ende der 1980er Jahre das World Wide Web. Dabei wurde die Notwendigkeit einer standardisierten Methode erkannt, um Ressourcen im Netz eindeutig zu identifizieren und darauf zuzugreifen. Aus diesem Bedarf heraus entstand 1991 die URL.

Aufbau einer URL

Typischerweise besteht sie aus mehreren Teilen:

1. Protokoll: Definiert, welches Übertragungsprotokoll man verwendet (z.B. HTTP, HTTPS, FTP).
2. Domainname: Gibt die Webseite oder den Server an, auf den zugegriffen wird.
3. Pfad: Spezifiziert den genauen Ort der Ressource auf dem Server.
4. Parameter: Optionale Informationen, die man an den Server sendet.

Beispiel: https://www.beispiel.de/pfad/unterpfad?parameter=wert

Beste Praktiken bei der Umsetzung von URLs

Die Erstellung einer klaren, konsistenten und benutzerfreundlichen URL-Struktur bietet zahlreiche Vorteile:

• Benutzerfreundlichkeit: Kurze, beschreibende URLs helfen dabei, den Inhalt der Seite vor dem Klick zu erahnen.
• Suchmaschinenoptimierung (SEO): Klare und relevante URLs bewerten Suchmaschinen positiv. Dies erleichtert die Indexierung und das Ranking der Seite. Siehe auch den Beitrag über SEO.
• Sharing: Gut strukturiert lässt es sich einfacher teilen und merken.

Tipps für optimierte URLs:

• Klarheit: Klare und verständliche Wörter verwenden.
• Kürze: Unnötige Wörter und Pfade vermeiden.
• Struktur: Bindestriche anstelle von Unterstrichen verwenden, um Wörter zu trennen.
• Dynamische Parameter vermeiden: Wo möglich, statische, beschreibende URLs verwenden.

Worauf zu achten ist

• Sicherheit: HTTPS verwenden, um den Datenverkehr zu verschlüsseln.
• Duplizierte Inhalte: Sicherstellen, dass jede Seite eine eindeutige URL besitzt.
• Weiterleitungen: Bei geänderten URLs 301-Weiterleitungen nutzen.

Fazit

Die URL ist ein zentrales Element des Webs und fungiert nicht nur als digitale Adresse, sondern auch als Instrument für Markenpräsenz und Benutzererfahrung. Durch Verständnis ihrer Geschichte und Beachtung der besten Praktiken lässt sich die Effektivität und Reichweite einer Webseite steigern.

Der Beitrag URL – Von ihrer Entstehung bis zur modernen Optimierung erschien zuerst auf CEOsBay.

Grundlagen

Warum OAuth?

• Benutzerkontrolle: OAuth ermöglicht es Benutzern, Anwendungen und Diensten den Zugriff auf ihre Konten bei verschiedenen Anbietern zu gewähren, ohne dabei ihre Benutzername/Passwort-Kombinationen preiszugeben.

• Sicherheit: Da die Anmeldeinformationen nicht direkt geteilt werden, reduziert OAuth das Risiko von Datendiebstahl und Missbrauch von Anmeldeinformationen.

• Granulare Berechtigungen: OAuth erlaubt es Benutzern, den Umfang und die Dauer der Zugriffsberechtigungen, die an eine Anwendung vergeben werden, präzise zu steuern.

Hauptkomponenten von OAuth

• Ressourcenbesitzer (Resource Owner)
  Der Ressourcenbesitzer ist normalerweise der Endbenutzer, der den Zugriff auf seine Daten und Ressourcen bei einem Ressourcenserver gewährt.

• Ressourcenserver (Resource Server)
  Der Ressourcenserver hostet die geschützten Daten und Ressourcen des Ressourcenbesitzers. Er ist dafür verantwortlich, die Autorisierung und Authentifizierung von Anfragen mithilfe von OAuth-Tokens zu überprüfen. (Kleiner Tipp am Rande. Bei den Tokens handelt es sich nicht um die Tokens, die man aus den Kryptowährungen kennt 😉 )

• Client
  Die Client-Anwendung ist der Konsument der geschützten Ressourcen. Sie stellt Anfragen an den Ressourcenserver, um im Namen des Ressourcenbesitzers auf die Daten zuzugreifen.

• Autorisierungsserver (Authorization Server)
  Der Autorisierungsserver ist für die Ausgabe, Überprüfung und den Widerruf von OAuth-Zugriffstokens zuständig. Er agiert als Vermittler zwischen dem Ressourcenbesitzer, dem Client und dem Ressourcenserver.

OAuth-Fluss

Man kann den OAuth-Fluss in vier grundlegende Schritte unterteilen:

• Anfordern der Autorisierung: Der Client fordert die Autorisierung des Ressourcenbesitzers an, um auf dessen Ressourcen zuzugreifen.

• Autorisierungsantwort: Der Ressourcenbesitzer gewährt die Autorisierung und leitet den Client an den Autorisierungsserver weiter. Der Client erhält einen Autorisierungscode.

• Anfordern eines Zugriffstokens: Der Client sendet den Autorisierungscode an den Autorisierungsserver und fordert ein Zugriffstoken an.

• Token-Ausgabe: Der Autorisierungsserver überprüft den Autorisierungscode, stellt ein Zugriffstoken aus und sendet es an den Client.

Nachdem der Client das Zugriffstoken erhalten hat, kann er es verwenden, um auf die geschützten Ressourcen des Ressourcenbesitzers zuzugreifen, indem er Anfragen an den Ressourcenserver stellt. Der Ressourcenserver überprüft das Token und gewährt den Zugriff entsprechend der Berechtigungen, die vom Ressourcenbesitzer festgelegt wurden.

Versionen und Unterschiede von OAuth

Es gibt zwei Hauptversionen. OAuth 1.0 und OAuth 2.0. Die Veröffentlichung von OAuth 1.0 fand im Jahr 2010 statt und verwendet einen komplexeren kryptografischen Ansatz für die Sicherheit. Im Jahr 2012 folgte OAuth 2.0 und ist eine überarbeitete Version, die eine einfachere und flexiblere Architektur bietet. Zweiteres basiert auf Bearer-Tokens. Bei beiden handelt es sich nach wie vor um offene Standardprotokolle zur sicheren Delegierung von Zugriffsberechtigungen. Obwohl sie gemeinsame Ziele verfolgen, unterscheiden sie sich in ihrer Architektur, ihren Sicherheitsmechanismen und besonders in der Benutzerfreundlichkeit. Durch die unterschiedliche Architektur ist keine Abwärtskompatibilität gegeben.

Sicherheitsmechanismen:

1.0: Verwendet einen kryptografischen Ansatz, bei dem man Anfragen mithilfe von kryptografischen Signaturen und einem gemeinsamen Geheimnis (Shared Secret) zwischen dem Client und dem Autorisierungsserver signiert. Diese Methode erfordert einen erhöhten Aufwand bei der Implementierung und Konfiguration.

2.0: Verwendet Bearer-Token, bei denen der Besitzer des Tokens (Client) Zugriff auf die geschützten Ressourcen erhält. Die Sicherheit basiert hauptsächlich auf der sicheren Übertragung und Aufbewahrung von Tokens (z. B. über https). Diese Methode ist einfacher zu implementieren und erfordert weniger kryptografische Kenntnisse.

Flexibilität:

1.0: Bietet einen starren Ablauf zur Anforderung und Nutzung von Zugriffstokens, der weniger Anpassungsmöglichkeiten für verschiedene Anwendungsszenarien bietet.

2.0: Ermöglicht eine größere Flexibilität und Anpassungsfähigkeit, indem man verschiedene „Grant Types“ (Genehmigungsarten) zur Verfügung stellt, um unterschiedlichen Anwendungsszenarien und Plattformen Genüge zu tun.

Einfachheit:

1.0: Die Implementierung und das Debugging von OAuth 1.0 können komplex sein, da Entwickler den kryptografischen Prozess und das Signieren von Anfragen verstehen müssen.

2.0: Die Implementierung von OAuth 2.0 ist einfacher und erfordert weniger kryptografische Kenntnisse. Dies führt zu einer schnelleren und einfacheren Integration in Anwendungen und Dienste.

Mobile und native Anwendungen:

1.0: Aufgrund seiner komplexeren Natur und der kryptografischen Anforderungen ist OAuth 1.0 weniger geeignet für mobile und native Anwendungen, bei denen Ressourcen und Konnektivität eingeschränkt sein können.

2.0: Durch die einfachere Implementierung und den flexibleren Ablauf eignet sich OAuth 2.0 besser für die Integration in mobile und native Anwendungen.

Vorteile

Sicherheit: Es erhöht die Sicherheit, indem man Anmeldeinformationen nicht direkt teilen muss und Tokens verwendet, um auf Ressourcen zuzugreifen.

Benutzerfreundlichkeit: Es ermöglicht Single Sign-On (SSO) und reduziert die Notwendigkeit, mehrere Benutzernamen und Passwörter zu verwalten.

Flexibilität: Es bietet eine flexible Architektur, die für verschiedene Anwendungsszenarien und Plattformen geeignet ist.

Granularität: Es ermöglicht, den Umfang und die Dauer der gewährten Berechtigungen genau zu steuern.

Nachteile

Komplexität: Die Implementierung von OAuth, insbesondere bei OAuth 1.0, kann komplex sein, da es verschiedene Abläufe und Mechanismen beinhaltet. Dies kann zu einer steileren Lernkurve für Entwickler führen, die sich nicht mit dem Protokoll auskennen.

Sicherheitsrisiken: Trotz der verbesserten Sicherheit, die OAuth bietet, gibt es immer noch Sicherheitsrisiken. Fehlkonfigurationen, unzureichende Validierungen und direkte Angriffe auf den Autorisierungscode oder das Zugriffstoken können die Sicherheit weiter gefährden.

Abhängigkeit von Drittanbietern: Die Verwendung von OAuth kann eine Abhängigkeit von Drittanbieter-Autorisierungsservern schaffen, die möglicherweise Ausfallzeiten, Sicherheitsverletzungen oder andere Probleme aufweisen können.

Datenschutzbedenken: Bei der Verwendung von OAuth besteht das Risiko, dass Benutzer mehr Daten preisgeben als erforderlich, da Anwendungen möglicherweise Zugriff auf mehr Informationen anfordern, als für ihre Funktionen notwendig ist.

Token-Hijacking: Obwohl es die Sicherheit gegenüber der direkten Weitergabe von Anmeldeinformationen verbessert, besteht immer noch die Gefahr, dass Angreifer Zugriffstoken abfangen oder stehlen können. Dies kann zu unbefugtem Zugriff auf Benutzerdaten führen.

Eingeschränkte Implementierung: Die Nutzung von OAuth in bestimmten Anwendungsszenarien, wie beispielsweise bei Geräten mit eingeschränkter Internetkonnektivität oder eingeschränkten Eingabemöglichkeiten, kann sich als schwierig oder teilweise unmöglich gestalten.

Best Practices

• Man sollte immer die neueste Version (aktuell OAuth 2.0) für bessere Sicherheit und Flexibilität verwenden.
• Implementierung von „Proof Key for Code Exchange“ (PKCE) Erweiterung ist zu empfehlen, um Angriffe, die den Autorisierungscode abfangen, verhindern zu können.
• Sichere Speicherung des Zugriffstokens und der Client-Anmeldeinformationen, um den Missbrauch zu verhindern.
• Verwenden von kurzen Gültigkeiten und Lebensdauern für Zugriffstokens und Erneuerungen bei Bedarf mithilfe von Aktualisierungstokens.
• Implementierung von Zustimmungsbildschirmen, um Benutzer über den Umfang und die Dauer der Berechtigungen, die man gewährt, zu informieren.

Fazit:

OAuth ist ein leistungsstarkes Protokoll, das die sichere Delegierung von Zugriffsberechtigungen im Internet ermöglicht. Durch das Verständnis der Grundlagen von OAuth und die Einhaltung der Best Practices können Entwickler Anwendungen erstellen, die eine sichere und benutzerfreundliche Erfahrung bei Login-Verfahren bieten.

Der Beitrag OAuth – Login ohne Preisgabe von Anmeldeinformationen erschien zuerst auf CEOsBay.

Was ist eine API?

Eine API (Application Programming Interface) ist eine Sammlung von Protokollen, Routinen und Tools zur Interaktion zwischen verschiedenen Softwareanwendungen. Vereinfacht ausgedrückt, ermöglicht eine API die Kommunikation zwischen zwei Softwareanwendungen, indem sie dem Entwickler die Möglichkeit bietet, bestimmte Funktionen oder Daten einer Anwendung zu verwenden, ohne sich um deren interne Implementierung kümmern zu müssen.

Funktionsweise von APIs

APIs ermöglichen die Kommunikation zwischen Anwendungen, indem sie standardisierte Anfragen und Antworten verwenden. In der Regel bezeichnet man eine Anwendung, die eine API bereitstellt, als Server. Die Anwendung, die die API nutzt, bezeichnet man als Client. Der Client sendet eine Anfrage an den Server, der diese Anfrage bearbeitet und daraufhin eine Antwort zurücksendet.

Die Kommunikation erfolgt meist über das https-Protokoll und basiert auf einem Request-Response-Modell. Eine API-Anfrage enthält normalerweise Informationen wie die gewünschte Aktion, die zu verwendenden Daten und den Authentifizierungsschlüssel. Die Antwort beinhaltet dann das Ergebnis der Aktion, zusammen mit den angeforderten Daten, falls vorhanden.

Arten von APIs

Es gibt verschiedene Arten von APIs, je nach Zugriffsbeschränkungen und Anwendungsbereich. Hier sind einige der gebräuchlichsten Typen:

Öffentliche APIs: Auch als externe oder offene APIs bekannt, sind APIs, die für die Öffentlichkeit zugänglich sind. Entwickler können sie nutzen, um angebotene Dienste in ihre Anwendungen zu integrieren.

Private APIs: Diese APIs sind nur für einen bestimmten Entwicklerkreis oder innerhalb eines Unternehmens zugänglich. Entwickler verwenden sie, um interne Prozesse und Dienstleistungen zu unterstützen.

Partner-APIs: Partner-APIs sind für eine ausgewählte Gruppe von Entwicklern oder Unternehmen zugänglich, die eine Partnerschaft oder Geschäftsvereinbarung mit dem API-Anbieter eingegangen sind.

API-Protokolle und Datenformate

APIs nutzen verschiedene Protokolle und Datenformate, um Anfragen und Antworten zu strukturieren. Die gebräuchlichsten sind:

REST (Representational State Transfer): Ein Architekturstil, der auf der Verwendung von standardisierten https-Anfragen und Antworten basiert. REST-APIs sind ressourcenorientiert und relativ leicht verständlich. Man verwendet sie häufig mit JSON (JavaScript Object Notation) als Datenformat.

SOAP (Simple Object Access Protocol): Ein älteres Protokoll, das auf XML-basierten Nachrichten beruht und strenge Regeln für die Kommunikation vorschreibt. SOAP-APIs sind tendenziell komplexer als REST APIs, bieten jedoch eine höhere Sicherheit und formelle Spezifikationen.

GraphQL: Eine relativ neue API-Technologie, von Facebook. Im Gegensatz zu REST und SOAP ermöglicht GraphQL eine flexiblere Datenabfrage, indem der Client genau die benötigten Informationen anfordern kann. GraphQL verwendet eine eigene Abfragesprache und unterstützt sowohl Lese- als auch Schreiboperationen.

gRPC: Ein von Google entwickeltes API-Framework, das auf Protocol Buffers, als binäres Datenformat setzt und für hohe Leistungsfähigkeit und Skalierbarkeit optimiert ist. gRPC eignet sich besonders für Mikroservices und hochperformante Anwendungen. Ich gehe davon aus, dass ich darüber in naher Zukunft einen separaten Beitrag schreibe.

API-Authentifizierung und -Sicherheit

Um den Zugriff auf APIs zu kontrollieren und deren Sicherheit zu gewährleisten, kann man verschiedene Authentifizierungs- und Autorisierungsmechanismen einsetzen. 

Einige der gängigen Methoden sind:

API-Schlüssel: Ein einfacher und weit verbreiteter Ansatz, bei dem der Entwickler einen eindeutigen Schlüssel erhält, den man bei jeder API-Anfrage übermittelt, um den Zugriff zu autorisieren.

OAuth: Ein offener Standard für Authentifizierung und Autorisierung, der es ermöglicht, Anwendungen den Zugriff auf Benutzerdaten von Drittanbietern zu gewähren, ohne dass die Anwendung das Passwort des Benutzers kennen muss. Sozialen Netzwerke und große Webdienste wie Google und Facebook nutzen häufig OAuth.

JWT (JSON Web Tokens): Eine kompakte, selbstständige Methode zur sicheren Übertragung von Informationen zwischen Parteien in Form von Objekten. Man nutzt JWTs häufig in Kombination mit OAuth und anderen Authentifizierungsschemata.

Best Practices bei der Verwendung von APIs

Die erfolgreiche Nutzung von APIs erfordert einige Best Practices, um sicherzustellen, dass Anwendungen effizient und sicher arbeiten:

Dokumentation: Eine gut dokumentierte API erleichtert Entwicklern das Verständnis und die Integration der API in ihre Anwendungen.

Fehlerbehandlung: Eine robuste Fehlerbehandlung ist entscheidend, um sicherzustellen, dass Anwendungen auch bei unerwarteten Fehlern oder Ausfällen der API korrekt funktionieren.

Ressourcenmanagement: Bei der Verwendung von APIs ist es wichtig, auf Ressourcenmanagement zu achten. Dies erreichet man beispielsweise, indem man Ratenbegrenzungen (Rate Limiting) einhält, um die Anzahl der Anfragen pro Zeiteinheit zu begrenzen und die Belastung des API-Servers zu reduzieren.

Sicherheit: Bei der Arbeit mit APIs sollte man auf die Sicherheit der Anwendung und der API achten. Durch die Verwendung von Verschlüsselungstechniken und sicheren Authentifizierungsmethoden lässt sich dies relativ einfach realisieren.

Zukünftige Trends bei APIs:

APIs gewinnen weiterhin an Bedeutung, da sich die Technologielandschaft weiterentwickelt. Um neue Anforderungen und Herausforderungen zu bewältigen, müssen sich auch die APIs weiterentwickeln.

Einige zukünftige Trends bei APIs sind:

Hypermedia-APIs: Ein aufkommender Trend im Bereich der REST APIs ist die Verwendung von Hypermedia-Elementen zur Dynamisierung der API-Kommunikation. Hypermedia-APIs stellen Links und Aktionen in den API-Antworten bereit, um den Client zur Verfügung stehende Funktionen und Ressourcen dynamisch zu erkennen. Dadurch kann man die Kopplung zwischen Client und Server reduzieren.

API-Orchestrierung: Mit der zunehmenden Verbreitung von Mikroservices und verteilten Systemen gewinnen die API-Orchestrierung und -Aggregationen immer mehr an Bedeutung, um eine effiziente Kommunikation und Integration zwischen verschiedenen Diensten zu gewährleisten.

Edge-Computing und APIs: Mit der zunehmenden Verbreitung von IoT-Geräten und Edge-Computing-Technologien ist die Rolle von APIs bei der Bereitstellung von Echtzeitdaten und Funktionen für Geräte am Netzwerkrand essenziell.

KI-gestützte APIs: Integration von künstlicher Intelligenz und maschinellem Lernen, um leistungsfähige Funktionen wie Spracherkennung, Computer Vision bzw. Bildanalyse und datengesteuerte Vorhersagen bereitzustellen.

API-Sicherheit und Datenschutz: Angesichts der wachsenden Besorgnis über Datensicherheit und Datenschutz nimmt man APIs zunehmend unter die Lupe, um sicherzustellen, dass sie den geltenden Datenschutzbestimmungen entsprechen und angemessene Sicherheitsmaßnahmen implementieren.

Fazit

APIs sind ein grundlegendes Element moderner Softwareentwicklung und ermöglichen eine effiziente und skalierbare Kommunikation zwischen verschiedenen Anwendungen und Diensten. Durch das Verständnis der verschiedenen API-Typen, Protokolle, Datenformate und Best Practices können Entwickler ihre Anwendungen effektiv erweitern und mit externen Diensten integrieren. Indem man auf API-Dokumentation, Fehlerbehandlung, Ressourcenmanagement und Sicherheit achtet, kann man sicherstellen, dass die API-Integration erfolgreich ist und zur Verbesserung der Gesamtanwendung beiträgt.

Der Beitrag API – Nahtlose Verbindungen für Innovationen erschien zuerst auf CEOsBay.

Es stützt sich auf XML zur Repräsentation der Daten und auf Internet-Protokolle der Transport- und Anwendungsschicht zur Übertragung der Nachrichten. Die gängigste Kombination ist SOAP über https (Hypertext Transfer Protocol) und TCP (Transmission Control Protocol). Man kann SOAP auch über das SMTP (Simple Mail Transfer Protocol) oder JMS (Jakarta Messaging) verwenden.

Die mit der Nachricht übermittelten Nutzdaten man nicht zwingend in XML senden. Andere Formate wie Base64 oder CSV sind ebenfalls möglich. Seit Version 1.2. nutzt man die Abkürzung SOAP offiziell nicht mehr als Akronym, da es erstens (subjektiv) keineswegs einfach (Simple) ist und zweitens nicht nur dem Zugriff auf Objekte (Object Access) dient.

Kurze Zeitreise

SOAP entstand aus der Weiterentwicklung der Spezifikation für XML-RPC im Jahr 1998. Hauptverantwortlicher Software-Entwickler damals Dave Winer und seine Firma UserLand Software in engem Austausch mit Microsoft. Dave Winter ist übrigens auch für RSS 2.0 verantwortlich. Einen Beitrag über RSS findet man hier.

Im Jahr 1999 fand die Veröffentlichung der Version 1.0 von SOAP statt. Dies stellt unter Anderem den Zeitpunkt dar, an dem die Entwicklung mehr Unterstützung fand. Vor allem hat sich IBM im Jahr 2000 der Entwicklung angeschlossen, was dazu führte, dass IBM, Microsoft, DevelopMentor (Don Box) und UserLand Software (Dave Winer) die Spezifikation von SOAP 1.1 beim World Wide Web Consortium (W3C) einreichten. Dabei hat man das Ziel verfolgt, eine Arbeitsgruppe zu gründen, die SOAP weiterentwickeln sollte. Das Ergebnis dieser Arbeitsgruppe ist SOAP Version 1.2, empfing im Juni 2003 die Anerkennung als recommendation (Empfehlung).

Wie zu Beginn des Beitrags erwähnt, hat man SOAP nicht mehr als gebräuchliche(s) Akronym bzw. Abkürzung verstanden. Der Hauptgrund dafür ist die Tatsache, dass sämtliche Deutungen für SOAP, wie Simple Object Access Protocol oder Service Oriented Architecture Protocol, nicht mehr den vollständigen Sinn von SOAP trafen. Dies ermöglichte die Anmeldung von SOAP als Markennamen in den USA.

Wie funktioniert SOAP?

SOAP ist wie zuvor beschrieben, ein Protokoll zum Austausch XML-Information-Set-basierter Nachrichten über ein Rechnernetz und hat den Status einer W3C-Empfehlung. Es stellt Regeln für das Nachrichtendesign auf. Regelt, wie Daten in der Nachricht abzubilden und zu interpretieren sind. Es gibt eine Konvention für entfernte Prozeduraufrufe mittels SOAP-Nachrichten vor. SOAP macht keine Vorschriften zur Semantik applikationsspezifischer Daten, die man gegebenenfalls versendet möchte, sondern stellt ein Framework (Siehe meinen Beitrag) zur Verfügung, welches erlaubt, dass man beliebige applikationsspezifische Informationen übertragen kann.

Man kann SOAP für entfernte Prozeduraufrufe ebenso nutzen wie für einfache Nachrichtensysteme. Zum Senden von Nachrichten kann man beliebige Transportprotokolle verwendet. Dazu gehören beispielsweise FTP, SMTP, https oder auch JMS. Aus Gründen der Kompatibilität nutzt man in der Praxis hierzu gängige Netzwerk-Architekturen. Auch ist mittels https die verschlüsselte Übertragung von SOAP-Nachrichten möglich. Das ermöglicht jedoch keine End-to-End-Verschlüsselung. Dies kann man durch WS-Security erreichen. Die Einbindung erfolgt lediglich auf der Ebene der Nachrichten und nicht auf der des unterliegenden Transportprotokolls. Folglich ist es so, dass man das XML Information Set der SOAP-Anfrage bei Nutzung von https(S) im Body eines https POST Requests als XML an eine gegebene URL schickt.

In der Regel setzt man SOAP da ein, wo der direkte Zugang fremder Systeme zu einer Informationsquelle nicht sinnvoll erscheint. Dies kann sowohl an Kompatibilitätsproblemen zwischen verschiedenen Anwendungsarchitekturen liegen aber auch an diversen Sicherheitsaspekten. So kann man einen (partiellen) Zugriff auf eine Datenbank ermöglichen, ohne dem Anwenderprogramm den direkten Zugang zu ermöglichen. Die Menge der ausführbaren Methoden reglementiert und definiert man über die SOAP-Schnittstelle.

Die Kommunikation mit SOAP ermöglicht die Kopplung von Systemen. Der offene Entwurf ermöglicht jedoch lediglich den Aufbau schwach gekoppelter Systeme. Die Flexibilität des Konzeptes erkauft man sich durch die Nachteile beim Übertragungsvolumen und Rechenaufwand. Dies kann teuer werden, da man das XML-Dokument beim Sender zunächst aufbaut und anschließend validiert. Das Konzept verfolgt eigentlich das Ziel eines leichtgewichtigen Protokolls.

Doch durch den flexiblen Einsatzbereich führt die zu übertragende Datei eine Reihe von Metadaten mit sich, die bei der Konstruktion des XML-Dokuments weiter anwächst. So führt beispielsweise das einfache Versenden von „Wahr“ oder „Falsch“ zu einem Datenvolumen von mehreren hundert Bytes. In einem stark gekoppelten System sollte dafür theoretisch ein Bit reichen.

Durch die Möglichkeit des flexiblen Aufbaus des Dokuments kann man jedoch auch komplexe Transaktionen in einer Anfrage atomar zusammenfassen, während man in stark gekoppelten Systemen hierzu oftmals mehrere Anfragen erstellen muss. Dies verbessert das Nutzlastverhältnis (Nutzdaten zu Meta-Daten) und den Kommunikationsaufwand (für den Aufbau einer Verbindung, nur ein Senden/Empfangen).

SOAP unterscheidet zwischen dem endgültigen Empfänger und den Zwischenempfängern. Dies ermöglicht es, eine Nachricht über verschiedene „Hops“ zu schicken, bei denen man sogar verschiedene Transportprotokolle verwendet. Beispielsweise kann man zum ersten Hop die Nachricht mittels Java Message Service schicken, im Anschluss über E-Mail und schließlich dem Empfänger mittels https weitergeben. Der Absender muss über die Zwischenhops keine Information haben, die Middleware jedoch schon.

Wie ist eine SOAP-Nachricht aufgebaut?

Eine minimale SOAP-Nachricht besteht aus einem Envelope genannten Element, dem man einen lokalen Namen zuweisen muss. Dieses Element referenziert mittels eines Namensraum-Attributes auf https://www.w3.org/2003/05/soap-envelope. Child dieses Elements muss ein Body-Element sein. Optional kann zuvor ein Header-Element stehen. In diesem kann man Meta-Informationen, beispielsweise zum Routing, zur Verschlüsselung oder zu Transaktionsidentifizierung, unterbringen. Im Body-Element sind die eigentlichen Nutzdaten untergebracht. Dies sieht dann folgendermaßen aus:

<?xml version="1.0"?>
<s:Envelope xmlns:s="https://www.w3.org/2003/05/soap-envelope">
    <s:Header>
    </s:Header>
    <s:Body>
    </s:Body>
</s:Envelope>

Innerhalb des Body-Elements können sowohl Informationen zum Datenaustausch als auch Anweisungen für einen entfernten Prozeduraufruf stehen. Dies ist vom Empfänger entsprechend zu interpretieren.

Im Header gibt man den nächsten Hop (intermediary) und den endgültigen Empfänger (ultimate recipient) an. Ein intermediary kann beispielsweise die Nachricht verschlüsseln, sie loggen oder die Nachricht aufteilen. Ersteres erlaubt es, dass die Anwendungslogik sich nicht um die Sicherheit der Nachricht kümmern muss. Darum kümmert sich die Middleware. Was eine Middleware ist, erkläre ich in einem anderen Beitrag. Die Möglichkeit, dass Intermediaries beliebige Dinge tun können, ermöglicht EAI (Enterprise Application Integration).

Fazit

Viele Altsysteme verwenden möglicherweise noch SOAP. In der Vergangenheit war es auch die Lösung schlechthin. Heute ist es eher REST, welches zum Einsatz kommt und in webbasierten Szenarien häufig als die schnellere Alternative gilt.

Zusammengefasst kann man sagen, dass REST aus einer Reihe von Richtlinien für eine flexible Implementierung besteht und SOAP ein Protokoll mit spezifischen Anforderungen wie XML-Messaging ist.

REST-APIs sind schlank und daher ideal für moderne Anwendungen geeignet, wie das Internet of Things (IoT), mobile Anwendungen und Serverless Computing. SOAP-Webservices bieten zwar integrierte Sicherheit und Transaktions-Compliance, die vielen Unternehmensanforderungen entspricht, doch die Erstellung und Wartung ist wesentlich aufwändiger. Darüber hinaus folgen auch viele öffentlich zugängliche APIsheutzutage, den REST-Richtlinien.

Der Beitrag SOAP – Effiziente Möglichkeit, um Daten zwischen Systemen zu übertragen erschien zuerst auf CEOsBay.

Der Zweck von REST liegt schwerpunktmäßig auf der Maschine-zu-Maschine-Kommunikation. REST stellt eine einfache Alternative zu ähnlichen Verfahren wie SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) und dem verwandten Verfahren RPC (Remote Procedure Call) dar. Anders als bei vielen verwandten Architekturen kodiert REST keine Methodeninformation in den URI (Uniform Resource Identifier), da der URI Ort und Namen der Ressource angibt, nicht aber die Funktionalität, die der Web-Dienst zu der Ressource anbietet. Der Vorteil von REST liegt darin, dass im WWW bereits ein Großteil der für REST nötigen Infrastruktur (z. B. Web- und Application-Server, https-fähige Clients, HTML- und XML-Parser, Sicherheitsmechanismen) vorhanden ist und viele Web-Dienste per se REST-konform sind. Eine Ressource kann dabei über verschiedene Medientypen dargestellt werden, auch Repräsentation der Ressource genannt.

So ist ein Online-Dienst, der lediglich unveränderte Seiteninhalte nach dem Internetstandard https anbietet, bereits REST-konform. Dynamisch erzeugte Seiten folgen diesem Paradigma jedoch meistens nicht. So bieten beispielsweise Nachrichtenseiten sich ständig ändernde Informationen mit sowohl unterschiedlichem Format als auch Inhalt an, die nur schwer automatisch verarbeitet werden können. Bliebe das Format unverändert, so wäre eine essenzielle REST-Eigenschaft erfüllt. So ist eine Webseite, auf der ständig die aktuelle Uhrzeit in immer demselben Format abrufbar ist, REST-konform.

Die Bezeichnung „Representational State Transfer“ soll den Übergang vom aktuellen Zustand zum nächsten Zustand (State) einer Applikation verbildlichen. Dieser Zustandsübergang erfolgt durch den Transfer der Daten, die den nächsten Zustand repräsentieren.

Kurze Zeitreise

Das REST-Paradigma entwickelte sich aus dem 1994 von Roy Fielding entworfenen https Object Model. Fielding entwickelte seine Idee von einem einheitlichen Konzept über die Jahre weiter, bis er 2000 den REST-Architekturstil im Rahmen seiner Dissertation (Hier der Link zu der Arbeit) veröffentlichte. Das Programmierparadigma der „RESTful Application“ wurde allerdings häufig falsch umgesetzt und findet erst seit 2014 Anklang in der Welt des WWW. In seiner Arbeit geht Fielding dabei auf die verschiedenen Anforderungen ein, die für die Webarchitektur wichtig sind.

Wie funktioniert REST?

Der Architektur-Stil verweist auf sechs Eigenschaften, die ein Dienst haben muss. Dabei ist nicht festgelegt, wie man diese Prinzipien implementieren muss. Fielding beschreibt für jedes Architekturprinzip dessen Vor- und Nachteile. Dabei handelt es sich um Client-Server, Zustandslosigkeit, Caching, Einheitliche Schnittstellen, Mehrschichtige Systeme und optional Code on Demand, auf die ich nachfolgend eingehen werde.

• Client-Server (Es gilt generell die Anforderung, dass alle Eigenschaften der Client-Server-Architektur gelten. Der Server stellt dabei einen Dienst bereit, der bei Bedarf vom Client abgefragt wird. Der Hauptvorteil dieser Anforderung ist die einfache Skalierbarkeit der Server, da diese unabhängig vom Client agieren. Dies ermöglicht des Weiteren eine unterschiedlich schnelle Entwicklung der beiden Komponenten.)
  
• Zustandslosigkeit (Jede REST-Nachricht enthält alle Informationen, die für den Server bzw. für den Client notwendig sind, um die Nachricht zu interpretieren. Weder der Server noch die Anwendung soll Zustandsinformationen zwischen zwei Nachrichten speichern. Man spricht daher von einem zustandslosen (englisch: stateless) Protokoll. Jede Anfrage eines Clients an den Server ist insofern in sich geschlossen, als dass sie sämtliche Informationen über den Anwendungszustand beinhaltet, die vom Server für die Verarbeitung der Anfrage benötigt. Zustandslosigkeit in der hier beschriebenen Form begünstigt die Skalierbarkeit eines Webservices. Beispielsweise können eingehende Anfragen im Zuge der Lastverteilung unkompliziert auf beliebige Maschinen verteilt werden, da jede Anfrage in sich geschlossen ist und Anwendungsinformationen somit ausschließlich auf der Seite des Clients vorgehalten werden. Aus diesem Grund ist auf der Seite des Servers keine Sitzungsverwaltung erforderlich. In der Praxis nutzen deswegen viele https-basierte Anwendungen Cookies und andere Techniken, um Zustandsinformationen auf der Client-Seite zu behalten. Weiterhin begünstigt wird die Ausfallsicherheit, weil die Zustandslosigkeit fordert, dass transaktionale Datenübertragung in einem einzigen Seitenaufruf erfolgt. Die Zustandslosigkeit bringt dabei aber den Nachteil mit, dass sich die Netzwerkperformance verschlechtert. Da bei jeder Abfrage alle Informationen zum Interpretieren mitgeschickt werden müssen, sind aufwendigere Abfragen nötig, als wenn sich der Server die Interaktionen merken würde.)
  
• Caching (https-Caching soll genutzt werden, wobei aber gilt: Eine Anfrage, die nicht gestellt werden muss, ist die schnellste Anfrage. Fielding führt dabei den Nachteil auf, dass der Client auf veraltete Cache-Daten zurückgreifen könnte, statt die neue Ressource abzufragen. Wir kennen dies beispielsweise, wenn wir an einer Website unsere Änderungen vorgenommen haben aber die aktualisierten Informationen nach der Synchronisierung mit dem Server nicht richtig angezeigt werden bzw. lediglich die alten Informationen)
  
• Einheitliche Schnittstelle (Dies ist das Hauptunterscheidungsmerkmal aller weiteren Architekturstile. Dabei besteht diese aus vier weiteren Eigenschaften.)

1. Die Adressierbarkeit von Ressourcen, bei der jede Information, die über einen URI kenntlich gemacht wird, als Ressource gekennzeichnet wird. Jeder REST-konforme Dienst eine eindeutige Adresse hat und dem Uniform Resource Locator (URL). Diese „Straße und Hausnummer im Netz“ standardisiert den Zugriffsweg zum Angebot eines Webservices für eine Vielzahl von Anwendungen (Clients). Eine konsistente Adressierbarkeit erleichtert es außerdem, einen Webservice als Teil eines Mashups weiterzuverwenden.
   
2. Repräsentationen zur Veränderung von Ressourcen, wodurch die unter einer Adresse zugänglichen Dienste unterschiedliche Darstellungsformen (Repräsentationen) haben können. Ein REST-konformer Server kann je nachdem, was die Anwendung anfordert, verschiedene Repräsentationen einer Ressource ausliefern, z. B. in verschiedenen Sprachen oder Formaten (HTML, JSON oder XML) oder auch die Beschreibung oder Dokumentation des Dienstes. Die Veränderung einer Ressource (also deren aktuellen Status) soll nur über eine Repräsentation erfolgen.
   
3. Selbstbeschreibende Nachrichten, REST-Nachrichten sollen selbstbeschreibend sein. Dazu zählt u. a. die Verwendung von Standardmethoden. Über diese Standardmethoden lassen sich Ressourcen manipulieren.
   
4. „Hypermedia as the Engine of Application State“ (HATEOAS) laut Fielding die wichtigste Eigenschaft

Ziel ist die Einheitlichkeit der Schnittstelle und somit ihre einfache Nutzung. 

• Mehrschichtige Systeme, bei dem die Systeme mehrschichtig aufgebaut sein sollen. Dadurch reicht es, dem Anwender lediglich eine Schnittstelle anzubieten. Dahinterliegende Ebenen können verborgen bleiben und somit die Architektur insgesamt vereinfachen. Vorteile dabei sind die bessere Skalierbarkeit der Server, sowie eine mögliche Abkapselung durch Firewalls. Durch Cache-Speicher an den Grenzen (z.B. vom Server zum Web) steigert man die Effizienz der Anfragen (Siehe Caching).
  
• Code on Demand, wobei diese Forderung von Fielding optional ist. Unter Code on Demand versteht man die Übertragung an den Client Code erst im Bedarfsfall. Folglich zur lokalen Ausführung. Ein Beispiel hierfür wäre die Übertragung von JavaScript-Code bei einer HTML-Repräsentation.

Folglich kommt für die Umsetzung des REST-Paradigmas ein zustandsloses Client-Server-Protokoll zum Einsatz. Als Anwendungsschicht-Protokolle werden hauptsächlich https und https eingesetzt. Dies liegt unter anderem daran, dass sich diese im WWW etabliert haben, über einen vergleichsweisen einfachen Aufbau verfügen und mit so gut wie jeder Firewall kompatibel sind. REST vereinheitlicht die Schnittstelle zwischen Systemen auf eine überschaubare und bezüglich des zu erwartenden Verhaltens standardisierte Menge von Aktionen. Welche Aktionen dies sind, ist in REST nicht festgelegt aber alle Aktionen sind allgemein definiert. In der Regel durch die verwendeten Protokolle der Anwendungsschicht.

Während REST als Abstraktion des WWW keine spezielle Implementierung und kein spezielles Protokoll fordert, ist doch zu beobachten, dass fast ausschließlich https zum Einsatz kommt. Dadurch werden auch die Menge der Aktionen festgelegt.

Wird über https zugegriffen, so gibt die verwendete https-Methode, darunter GET, POST, PUT und DELETE, an, welche Operation des Dienstes gewünscht ist. https schreibt vor, dass GET „safe“ (sicher) sein muss, was bedeutet, dass diese Methode nur Informationen beschafft und keine sonstigen Effekte verursacht. Die Methoden GET, HEAD, PUT und DELETE müssen laut https-Spezifikation idempotent (dasselbe) sein, was in diesem Zusammenhang bedeutet, dass das mehrfache Absenden der gleichen Anforderung sich nicht anders auswirkt als ein einzelner Aufruf. Abhängig von der Implementierung können noch weitere https-Befehle unterstützt werden. Dazu gehören COPY, MOVE, MKCOL, LOCK und UNLOCK des WebDAV-Protokolls, sowie LINK und UNLINK aus RFC 2068. Bei der Kommunikation über UDP kann zudem das CoAP aus RFC 7252 statt https eingesetzt werden, welches leicht abweichende Bedeutungen für GET, POST, PUT und DELETE besitzt.

Fazit

Die meisten Unternehmen verwenden den REST-Architekturstil für die Entwicklung / Implementierung von Webdiensten, da es sich um eine einfache und benutzerfreundliche Oberfläche handelt, die weniger Schulung für die vorhandenen / neuen Mitglieder des Projekts erfordert. Unternehmen erwägen REST zusammen mit ihren vorhandenen Webdiensten.

Der Beitrag REST – Schönheit der einfachen Architektur erschien zuerst auf CEOsBay.

Änderungen am Protokoll werden von den Besitzern einer eigenen Kryptowährung und eines Governance-Tokens mit dem Namen UNI abgestimmt und dann von einem Entwicklerteam umgesetzt. UNI-Token wurden zunächst an frühe Nutzer des Protokolls verteilt: Jede Ethereum-Adresse, die vor dem 1. September 2020 mit Uniswap interagiert hatte, erhielt die Möglichkeit, 400 UNI-Token zu beanspruchen, die zu dem Zeitpunkt etwa 1.400 US-Dollar wert waren. Die Marktkapitalisierung des UNI-Tokens liegt Stand heute bei 4.3 Milliarden Euro.

Wie alles begann

Uniswap wurde am 2018 von Hayden Adams, einem ehemaligen Maschinenbauingenieur gegründet. Das Unternehmen Uniswap erhielt Investitionen von Risikokapitalfirmen, darunter Andreessen Horowitz, Paradigm Venture Capital, Union Square Ventures LLC und ParaFi. Händler und Investoren haben Uniswap primär wegen der Verwendung im dezentralen Finanzwesen (DeFi) genutzt.

Das Protokoll

Im Gegensatz zu zentralisierten Börsen nutzt Uniswap Liquiditätspools, statt als Market Maker zu fungieren. Dies geschieht, um primär effizientere Märkte zu schaffen. Einzelpersonen und Bots – so genannte „Liquiditätsanbieter“ – stellen der Börse Liquidität zur Verfügung, indem sie einem Smart Contract ein Token-Paar hinzufügen, dass von anderen Nutzern nach der Constant – Product Regel gekauft und verkauft werden kann. Im Gegenzug erhalten die Liquiditätsanbieter einen Prozentsatz der für dieses Handelspaar erzielten Handelsgebühren.

Bei jedem Handel wird eine bestimmte Menge an Token aus dem Pool für eine bestimmte Menge des anderen Tokens entfernt, wodurch sich der Preis anpasst. Für die Auflistung von Token werden keine Gebühren verlangt, so dass eine große Menge an Ethereum-Token verfügbar sind und die Nutzer sich nicht bei einer zentralen Stelle registrieren müssen.

Als Open Source kann der Code von Uniswap auch genutzt werden, um neue bzw. Alternative Börsen zu erschaffen. Ein solches Vorhaben in Deutschland erfordert meines Wissens nach einer Lizenz von der BaFin. Auch wenn die Gründung in einem anderen Land erfolgt, doch die Transaktionen von und in Deutschland stattfinden, kann eine solche selbsterstellte Plattform äußerst schnell in Verruf bringen, wenn man nicht im Besitz der notwendigen Lizenzen ist.

Sicherheit

Um es gleich vorwegzunehmen: Uniswap ist bereits seit mehreren Jahren auf dem Markt und kann als seriöse Plattform bezeichnet werden. Das hohe Handelsvolumen, dass pro Tag mittlerweile im 3-stelligen Millionen Euro Bereich „schwimmt“, spricht für das Vertrauen, welches Anleger der Plattform entgegenbringen.

Im April 2020 wurde die Website von Uniswap vorübergehend abgeschaltet, nachdem Hacker versucht hatten, mit einem Reentrancy-Hack in die Börse einzudringen.

Relativ zeitgleich bzw. wenig vorher wurde Lendf.me attackiert. Die hatten etwas weniger Glück. Denn die Hacker konnten mehr als 25 Millionen Dollar in Kryptowährung von der Kreditplattform entwenden.

Was ist ein Reentrancy-Hack?

Der Reentrancy-Hack ist eines der destruktivsten Angriffe, die in der Regel Solidity-Smart Contracts als Angriffsziel haben. Der Angriff erfolgt, wenn eine Funktion einen externen Aufruf an einen anderen nicht vertrauenswürdigen Smart Contract tätigt. Der nicht vertrauenswürdige Smart Contract ruft dann rekursiv die ursprüngliche Funktion auf, um Kryptowährung zu transferieren.

Wenn der Smart Contract seinen Status nicht aktualisiert, bevor der Transfer der Kryptowährung stattfindet, kann der Angreifer die Abhebungsfunktion wiederholen, um die Geldmittel des Smart Contracts abzuziehen.

Wie kann man nun dieses Protokoll bzw. die Plattform nutzen?

Hier geht es auf die Seite von Uniswap. Im Anschluss rechts oben auf Launch App und es kann losgehen. Im Grunde genommen erklärt sich alles von selbst.

Der Tausch

Wenn man eine bestimmte Kryptowährung swapen (tauschen) will, geht es auf den „Tauschen“ Reiter. Oben den Betrag eingeben, den man zur Verfügung stehen hat und unten die Währung, in die man tauschen will. Done. Hierbei sollte man auf jeden Fall die Transaktionskosten im Auge behalten. Auch wenn ETH mittlerweile das langerwartete Update erhalten hat, kann es relativ schnell teuer werden, wenn gerade viel auf der Chain los ist.

NFTs

Die NFTs gibt es unter dem Reiter NFTs. Genauso wie bei einem normalen Onlineshop die Ware anklicken, die Wallet verbinden und zahlen. Done.

Der Liquiditätspool

Zu dem Pool geht es über den Pool Reiter. Man benötigt immer ein Kryptowährungspaar. Folglich wählt man links und rechts jeweils eine Währung aus und stellt diese in dem sogenannten Pool zur Verfügung. Werden nun Transaktionen getätigt, die diese Token benötigen, wird man belohnt. Man kann es als provisionierte Entlohnung betrachten, weil man die Transaktionen erleichtert indem man Liquidität zur Verfügung stellt.

Gebühren

Bei der Anmeldung auf der Plattform und der Erstellung eines Liquiditätspools wird man mit 0,3 % an den Transaktionsgebühren der Pools beteiligt. Außerdem hat man Zugriff auf den prozentualen Anteil der Liquidität, den man bereitstellt. Wenn man also beispielsweise 60% der Gesamtliquidität für den Liquiditätspool bereitstellt, erhält man auch 60% der gesamten Transaktionsgebühren.

Wo gibt es den Source Code?

Hier auf GitHub.

Achtung

Ich empfehle ausdrücklich, immer die Verwendung von Hardware Wallets, wenn es um die Lagerung und Interaktion mit Kryptowährungen bzw. NFTs geht. Ich habe auf meinem Blog die Ledger und Trezor Wallet vorgestellt. Man sollte sich die Beiträge auf jeden Fall anschauen, wenn man beabsichtigt in diesem Bereich tätig zu werden. Nichtsdestotrotz No Financial Advice 😉

Der Beitrag Uniswap – Krypto Handelsplattform erschien zuerst auf CEOsBay.

Was ist Discord?

Mit Discord haben Benutzer die Möglichkeit, mit Sprachanrufen, Videoanrufen, Textnachrichten, Medien und Dateien in privaten Chats oder als Teil von Gemeinschaften, die „Server“ genannt werden, zu kommunizieren. Ein Server ist eine Sammlung von dauerhaften Chaträumen und Sprachkanälen, auf die über Einladungslinks zugegriffen werden kann. Die Anwendung läuft auf Windows, macOS, Android, iOS, iPadOS, Linux und in Webbrowsern. Es ist möglich, durch den Einsatz von Bots, wesentliche Funktionen auf diesen Servern zu administrieren und zu automatisieren.

Ein bisschen Background Information

Als Discord im Jahr 2015 auf den Markt kam, musste es sich gegen drei etablierte Apps behaupten: Skype, Slack und TeamSpeak. Alle drei taten, was sie sollten, doch waren sie nicht besonders gut darin. Dies ist wohl auch eines der Gründe, warum die Anwendung von Anfang an so viel Traffic und Zulauf erhielt. Der Andrang führte unweigerlich zu mehreren Serverabstürzen, da das Unternehmen sich schwertat, mit dem enormen Nutzerzahlen gleich zu Beginn klarzukommen.

Jason Citron, der Gründer von Discord, hatte gerade eine 100-Millionen-Dollar-Übernahme seiner vorherigen Social-Gaming-Technologie OpenFeint abgeschlossen. Er wusste, dass seine Anwendung durch einen modernen Ansatz für die Online-Kommunikation das Angebot von Skype und TeamSpeak bei weitem übertreffen konnte.

Anstatt auf Reddit oder in Foren zu suchen, konnten die Nutzer, die primär Gamer bzw. Spieler waren, einem Server beitreten, der speziell für ein bestimmtes Spiel gedacht war. Als die Server immer beliebter wurden, bekamen die Administratoren die Möglichkeit, Unterkanäle für bestimmte Themen oder Spielmodi hinzuzufügen.

Es gibt mittlerweile ca. 7 Millionen aktive Server auf Discord. Und mittlerweile kann man durchaus man sagen, dass eine nicht zu unterschätzende Zahl nicht mehr viel mit Spielen zu tun haben. Unter ihnen findet sich auch mein Unternehmens Server oder auch ein paar Server, in denen ich in Bezug auf NFTs und Krypto Teilhaber bin. Obwohl Discord nach wie vor für Gamer gedacht ist, hat das Team versucht, die Reichweite zu vergrößern, um mit Slack und Microsoft Teams zu konkurrieren. Und dies machen sie wirklich gut.

Die Möglichkeit, unmoderierte private Server zu erstellen, hat in der Vergangenheit auch für Kontroversen gesorgt. Im Jahr 2017 wurde ein Server von amerikanischen Nationalisten genutzt, um die Kundgebung in Charlottesville, Virginia, zu organisieren. Discord sperrte die Mitglieder der White-Supremacist-Gruppe und viele andere Neonazi- und Alternativ-rechte-Server und hat seitdem Verifizierungs- und Bot-Moderationstools eingeführt, um diese Art von Gruppen schneller aus dem Verkehr zu ziehen.

Wie bereits erwähnt, bot Discord zu Beginn nur Text- und Audiokommunikation. Im Jahr 2017 wurden Videoanrufe und Bildschirmfreigaben hinzugefügt. Später wurden auch Integrationen mit Twitch, Spotify und Xbox Live hinzugefügt.

Der Aufstieg von Discord kam mit dem Wachstum des E-Sports zusammen. Mit Spielen wie League of Legends, Overwatch und Fortnite, die allesamt über eher begrenzte Kommunikationstools verfügten. Als immer mehr Twitch-Streamer zu Discord wechselten, wurde dies zu einem Selbstläufer bzw. geradezu zu einer kostengünstigen Marketingkampagne für das Unternehmen.

Trotz des schnellen Wachstums, dass sich von 10 Millionen monatlich aktiven Nutzern (MAUs) im Jahr 2016 auf 45 Millionen im Jahr 2018 beschleunigte, kämpfte Discord damit, ein Einnahmemodell zu finden, dass die Erträge des Unternehmens sichern sollte. In den ersten Jahren verkaufte Discord digitale Aufkleber und Merchandise-Artikel. Aber diese Maßnahme brachte dem Unternehmen 2017 lediglich 10 Millionen US-Dollar ein.

Im Jahr 2018 wurde ein Spiele-Shop eingeführt, der eine ausgewählte Auswahl an Spielen bot. Außerdem wurde ein Abonnementdienst, Discord Nitro, eingeführt, der mehr Emojis, eine größere Uploadgröße, Serverunterstützung und Zugang zu den Videospielen im Schaufenster „Im Endeffekt Bildschirm-Sharing“ bot.

Während Discord Nitro noch immer im Einsatz ist, hat das Unternehmen die Funktion mit dem Spiele-Shop im Jahr 2019, mit der Begründung des mangelnden Interesses der Abonnenten entfernt. Seitdem hat es die Storefront auf Eis gelegt, die Discord oder den Spieleentwicklern von Drittanbietern offenbar nicht viel Geld einbrachte.

Trotz des Scheiterns der Storefront befindet sich Discord weiterhin in einer gesunden Position. Die Nutzung ist während der COVID-19-Ausgangssperre, die ja weitestgehend global realisiert wurde, sprunghaft angestiegen. Kürzlich wurden über 100 Millionen MAUs und ein neuer Höchststand von 10,6 Millionen gleichzeitig aktiven Nutzern bekannt gegeben.

Ob es in der Lage sein wird, Nutzer und Unternehmen von Slack und Microsoft Teams zu gewinnen, bleibt abzuwarten. Im März änderte es sein Motto von „Chat for Gamers“ in „Chat for Communities and Friends“ und gestaltete seine Website neu, um weniger Gamer-spezifische Inhalte zu zeigen. Kommt scheinbar im professionellen Umfeld nicht so gut an 😉

Ist Discord Open Source?

Discord ist nicht quelloffen und somit auch nicht Open Source. Obwohl es sich um einen geschlossenen Quellcode handelt, kommuniziert Discord selbst, dass sie als Unternehmen an die Open-Source-Entwicklungsprinzipien der Zusammenarbeit und der gemeinsamen Nutzung von Lösungen glauben. Es ist proprietär lizenziert, und der Source Code ist nicht frei zugänglich bzw. kann nicht modifiziert werden.

Warum ist Discord nicht Open Source?

Es ist anzunehmen, dass Discord keine Open-Source-Software ist, weil die Entwickler der App primär Geld verdienen möchten. Es erlaubt ihnen auch, die Software „begehrenswert“ zu halten. So zumindest die Aussage eines Mitarbeiters.

Da der Quellcode von Discord geschlossen ist, kann die Öffentlichkeit den Code der Discord-App nicht einsehen. Dies wirft viele Fragen darüber auf, was sich hinter dem Quellcode der Software verbirgt. Discord hat sich nicht zu den Spekulationen geäußert, warum es eine Closed-Source-Plattform ist. Die Geheimhaltung des Quellcodes kann Vorteile haben, muss es aber meiner Meinung nach nicht. Mich persönlich interessiert es, welche Daten erhoben werden.

Discord Bezahlmodell? 

Discord ist in der Standardversion kostenlos und bietet ein monatliches Abonnement mit dem Namen Discord Nitro an. Das Abonnement bietet Vorteile wie Streaming mit höherer Auflösung, das Hinzufügen von Änderungen an dem eigenen Server sowie größere Datenuploads.

Gibt es Alternativen zu Discord?

Klar gibt es Alternativen. Diese sind Mumble, Element, Tox.Chat, Jitsi, TeamSpeak und Skype.

Wobei ich persönlich, zusammen mit Discord, nur TeamSpeak, Mumble und Jitsi aktiv benutze. Evtl. werde ich auch Beiträge zu den alternativen Lösungen erstellen.

Fazit

Alles in allem finde ich persönlich Discord ok. Die Tatsache, dass der Quellcode nicht offen und somit Open Source ist, gefällt mir nicht. Auch gefällt es mir nicht, dass ich für den Einsatz von Bots extra Geld ausgeben muss, obwohl der Bot von mir persönlich entwickelt wurde und auch von mir selbst gehostet wird. Ich habe keine Ahnung, welche Daten der Kommunikation von Discord selbst erhoben werden. Wahrscheinlich sammeln sie alles.

Es gibt keinen Grund, paranoid zu sein, dennoch sollte man mit dieser Annahme gewissenhaft umgehen. Denn solange man nicht wirklich weiß, was unter der Haube läuft, kann man sich eben nicht sicher sein. Und die jüngsten Ereignisse in dem Kontext der sozialen Medien haben gezeigt, dass viel Unfug damit anstellen. Besonders fällt mir dies persönlich im Blockchain-, Krypto– und NFT-Space auf. Viele Projekte, in die ich investiert oder an denen ich beteiligt war, wurden meistens über Discord gehacked, da die Sicherheitsmaßnahmen nicht ausgefeilt genug waren.

Sicherlich gehört da auch die Gewissenhafte Verwaltung und Administration des eigenen Servers auch dazu, doch ich möchte Discord selbst mindestens genauso zur Verantwortung ziehen, da es ihre Anwendung ist, über den der Missbrauch stattfindet. Nichtsdestotrotz hat sich auch das NFT-Space mittlerweile regelrecht in Discord etabliert. Es ist abzuwarten, was Elon Musk mit Twitter anstellt. Vielleicht ergibt sich schon bald eine Alternative, die Discord zumindest im NFT-Space ablöst.

Dennoch muss ich sagen, dass ich ohne Discord wohl nicht auf grandiose Menschen gestoßen wäre, mit denen ich viel Zeit verbringe, um richtig gute Anwendungen und Lösungen zu entwickeln. Auch der Wissensgehalt, den ich mir lediglich durch die Nutzung der Plattform angeeignet habe, ist immens. Man findet halt relativ schnell Gleichgesinnte, mit einem gewissen Etwas 😉

Der Beitrag Discord – Community durch nahtlose Kommunikation und Zusammenarbeit 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.