Verschlüsselung, Authentifizierung und Validierung der Zertifizierungsstelle

In den letzten Versionen wurden die Sicherheitsfunktionen von 4D erheblich erweitert, insbesondere im Bereich der Zertifikate. Dazu gehören automatisch generierte Zertifikate für die Client-Server-Kommunikation, die Unterstützung von ECDSA-Zertifikaten und, mit 4D 20 R7, die Validierung von Zertifikatsautoritäten für die Client-Server-Kommunikation von vernetzten Anwendungen. Einige Kunden verlangen ein Höchstmaß an Sicherheit, was die Bedeutung dieser Funktionen unterstreicht.

Sicherheit kann jedoch komplex sein, und es gab Anfragen nach einer Erklärung, wie eine TLS/SSL-Verbindung funktioniert und welche Rolle Zertifikate spielen. Bevor wir uns mit den neuen Funktionen befassen, ist es daher hilfreich, zunächst die grundlegenden Sicherheitskonzepte und deren Zusammenspiel zu erläutern.

Verschlüsselung, Authentifizierung und Zertifikate

Das Herzstück der Sicherheit sind zwei Schlüsselkonzepte: Verschlüsselung und Authentifizierung. Die Verschlüsselung schützt Daten, indem sie sie verschlüsselt und so den unbefugten Zugriff zwischen einem Server und einem Client verhindert, während die Authentifizierung sicherstellt, dass sowohl der Client als auch der Server die sind, die sie vorgeben zu sein. Zertifikate decken beide Konzepte ab, da sie aus zwei Elementen (und damit zwei Dateien) bestehen: einem privaten Schlüssel, der zur Verschlüsselung der Kommunikation verwendet wird, und einem öffentlichen Zertifikat, das zur Authentifizierung verwendet wird.

Symmetrische Verschlüsselung

Die einfachste Form der Verschlüsselung ist die symmetrische Verschlüsselung, bei der Client und Server denselben Schlüssel verwenden, um ihre Kommunikation zu verschlüsseln. Die symmetrische Verschlüsselung hat den Vorteil, dass sie sowohl die Verschlüsselung als auch die Authentifizierung gewährleistet: Der Server ist gültig, da er den richtigen Schlüssel verwendet, und der Client ist aus demselben Grund gültig. Der größte Nachteil der symmetrischen Verschlüsselung ist die Notwendigkeit, den Schlüssel sowohl auf den Server als auch auf den Client zu kopieren, was einen separaten, sicheren Kommunikationskanal erfordert.

Asymmetrische Verschlüsselung

Die asymmetrische Verschlüsselung ist im Internet weit verbreitet und beruht auf einem einfachen Konzept: Sowohl der Client als auch der Server verfügen über öffentliche und private Schlüssel. Der öffentliche Schlüssel verschlüsselt die Kommunikation, während der private Schlüssel sie entschlüsselt. Der Server und der Client können ihre öffentlichen Schlüssel frei verteilen, ohne sich Gedanken über ein mögliches Abfangen zu machen, da der öffentliche Schlüssel nur die Verschlüsselung erlaubt. Ohne den privaten Schlüssel ist eine Entschlüsselung der Kommunikation nicht möglich.

In 4D wird die asymmetrische Verschlüsselung für den HTTP Server, den HTTP Client und die Kommunikation zwischen 4D Server und 4D Remote verwendet. Für den HTTP Server müssen das Zertifikat und der zugehörige Schlüssel im Projektordner abgelegt werden. Für die Kommunikation zwischen 4D Server und 4D Remote können das Zertifikat und der Schlüssel entweder im Ressourcenordner des 4D Servers gespeichert werden, oder der 4D Server kann sein Zertifikat automatisch generieren. Der HTTP Client und die 4D Gegenstelle generieren ihre Zertifikate automatisch.

Im Gegensatz zur symmetrischen Verschlüsselung gewährleistet die asymmetrische Verschlüsselung eine Verschlüsselung, aber keine Authentifizierung. Das bedeutet, dass nicht garantiert werden kann, dass der Server, mit dem kommuniziert wird, der beabsichtigte Server ist. Diese Schwachstelle kann zu Server-Impersonation und Man-in-the-Middle (MITM)-Angriffen führen (bei denen ein Angreifer die Kommunikation zwischen Client und Server abfängt).

Verhinderung von Server-Impersonationen und MITM: Validierung der Zertifizierungsstelle

Um Man-in-the-Middle-Angriffe zu verhindern, müssen sich der Client und der Server gegenseitig authentifizieren können. Für den Client wird in der Regel ein klassischer Anmelde-/Kennwortdialog verwendet, da man einen Benutzer nicht nur über eine Maschine authentifizieren möchte.

Eine der gängigsten Methoden zur Authentifizierung von Servern ist die Verwendung eines von einer vertrauenswürdigen Zertifizierungsstelle ausgestellten Zertifikats. Zertifizierungsstellen sind weltweit anerkannte Einrichtungen, deren Signaturen in Anwendungen wie Webbrowsern eingebettet sind. Wenn ein Server ein von einer Zertifizierungsstelle ausgestelltes Zertifikat vorlegt, kann der Client dessen Echtheit überprüfen, indem er die gespeicherte Signatur der Zertifizierungsstelle mit der des Zertifikats vergleicht.

Einführung in die Validierung von Zertifizierungsstellen in 4D 20 R7

Sehen wir uns nun die neue Funktion in 4D 20 R7 an: die Validierung von Zertifizierungsstellen für integrierte Anwendungen. Mit diesem Update können 4D Clients das Zertifikat, das sie vom 4D Server erhalten, überprüfen, um die Identität des Servers sicherzustellen und sich gegen Man-in-the-Middle (MITM) Angriffe zu schützen.

Um dies zu implementieren, müssen bei der Erstellung der Client-Anwendung zwei Werte zur Datei buildApp.4DSettings hinzugefügt werden: der Speicherort einer Datei mit Signaturen vertrauenswürdiger Zertifizierungsstellen, die in die Client-Anwendung kopiert werden, und der Domänenname des Server-Zertifikats. Mit diesen Informationen kann die Client-Anwendung überprüfen, ob das vom Server gesendete Zertifikat von einer gültigen Zertifizierungsstelle ausgestellt wurde und ob der Domänenname mit dem erwarteten Namen übereinstimmt. Bei Unstimmigkeiten wird die Verbindung abgelehnt.

In Fällen, in denen mehrere Clients beteiligt sind, kann es eine Herausforderung sein, für jeden Client eine eigene Anwendung zu erstellen. Daher kann eine Liste gültiger Domänennamen zur Verfügung gestellt werden. Dieser Ansatz ist zwar weniger sicher als die Angabe eines einzelnen Domänennamens, erfordert jedoch, dass ein potenzieller Man-in-the-Middle ein Zertifikat von einem der Clients besitzt, was nicht ohne weiteres möglich ist. Alternativ kann das Feld für den Domänennamen auch leer gelassen werden. In diesem Fall prüft 4D nur, ob das Zertifikat von einer gültigen Zertifizierungsstelle stammt.

Für Anwendungen, die über das Internet oder andere nicht vertrauenswürdige Netze kommunizieren, bietet diese Funktion eine wesentliche Schutzschicht für die Client-Server-Kommunikation.

Hilfe ist immer verfügbar – stellen Sie Ihre Fragen im 4D Forum.