Was ist ein TLS-Handshake?

4. Februar 2025

Ein Transport Layer Security (TLS)-Handshake stellt eine verschlรผsselte und authentifizierte Kommunikation zwischen einem Client (z. B. einem Webbrowser) und einem serverDer Handshake beinhaltet den Austausch von Nachrichten, die Vereinbarung kryptografischer Algorithmen, รœberprรผfung der server(und optional auch die des Clients) und die Generierung gemeinsamer geheime Schlรผssel zur Verschlรผsselung nachfolgender Datenรผbertragungen. Es ist die Grundlage fรผr einen sicheren Datenaustausch und gewรคhrleistet, dass รผbertragene Informationen vertraulich bleiben und nicht manipuliert werden kรถnnen.

Was ist ein TLS-Handshake?

Was bedeutet TLS-Handshake?

Ein TLS-Handshake ist eine Reihe von Schritten, die eine sichere Verbindung einleiten, indem die beteiligten Parteien validiert, kompatible Sicherheitsparameter ausgewรคhlt und gemeinsame Verschlรผsselungsschlรผssel erstellt werden. Der Handshake bestimmt, wie die Daten verschlรผsselt werden, รผberprรผft die serverund stellt den sicheren Kanal zum Schutz von Datenintegritรคt und Vertraulichkeit. Es ist ein wesentlicher Bestandteil von TLS, einem Protokoll, das Datenschutz und data security รผber Netzwerke.

Was sind die Komponenten eines TLS-Handshakes?

Nachfolgend sind die Hauptkomponenten aufgefรผhrt, die einen TLS-Handshake ermรถglichen.

Kunde und Server

Am Handshake sind zwei Haupteinheiten beteiligt: โ€‹โ€‹der Client, der die Verbindung initiiert (zum Beispiel ein Web-Browser oder andere Anwendung), und das server, die die Ressource oder den Dienst hostet, auf den der Client zugreifen mรถchte. Der Client startet den Handshake, indem er verschiedene Parameter vorschlรคgt fรผr Verschlรผsselung und Beglaubigungund der server antwortet mit den ausgewรคhlten Optionen basierend auf unterstรผtzten Konfigurationen.

Chiffre-Suiten

Eine Cipher Suite ist eine Sammlung kryptografischer Algorithmen, die wรคhrend des Handshakes und nachfolgender Datenรผbertragungen verwendet werden. Sie umfasst den Schlรผsselaustauschalgorithmus, die Massenverschlรผsselungs-Chiffre, den Nachrichtenauthentifizierungscode-Algorithmus und manchmal den digitalen Signaturalgorithmus. Der Client schlรคgt eine Liste der von ihm unterstรผtzten Cipher Suites vor, und die server wรคhlt eine aus, die es erkennt und fรผr akzeptabel hรคlt.

Zertifikate

Zertifikate sind digitale Dokumente, die zur Bestรคtigung der Identitรคt einer kommunizierenden Partei verwendet werden. Bei den meisten TLS-Verbindungen server prรคsentiert ein X.509-Zertifikat, das von einer vertrauenswรผrdigen Zertifizierungsstelle (CA). Dieses Zertifikat bindet die server Domain Name zu einem รถffentlichen Schlรผssel. Der Client รผberprรผft die Zertifikatskette, um sicherzustellen, dass sie nicht manipuliert wurde und von einer legitimen Zertifizierungsstelle ausgestellt wurde.

ร–ffentliche und private Schlรผssel

ร–ffentliche und private Schlรผssel sind integraler Bestandteil von TLS. server besitzt einen privaten Schlรผssel, der dem in seinem Zertifikat aufgefรผhrten รถffentlichen Schlรผssel entspricht. Wรคhrend des Handshakes nehmen diese Schlรผssel an asymmetrischen kryptografischen Operationen teil. Clients verwenden den รถffentlichen Schlรผssel im server Zertifikat zum Verschlรผsseln eines Datenelements (z. B. des Pre-Master-Geheimnisses) und nur das serverDer private Schlรผssel kann entschlรผsseln es.

Sitzungsschlรผssel

Sobald der Kunde und server einigen sich auf einen Satz kryptographischer Parameter, erzeugen sie symmetrische Sitzungsschlรผssel. Diese Schlรผssel verschlรผsseln und entschlรผsseln Nachrichten wรคhrend der Datenรผbertragungsphase und bieten sowohl Vertraulichkeits- als auch Leistungsvorteile. Symmetrische Verschlรผsselungsalgorithmen sind normalerweise viel schneller als asymmetrische, weshalb der Handshake asymmetrische Methoden zur Authentifizierung und zum Schlรผsselaustausch verwendet und dann fรผr die Massendatenverschlรผsselung auf symmetrische Methoden zurรผckgreift.

Wie funktioniert der TLS-Handshake?

Der TLS-Handshake lรคuft normalerweise in mehreren Schritten ab, die einen sicheren und authentifizierten Kanal gewรคhrleisten. Jede Phase hat einen definierten Zweck und besteht aus Nachrichtenaustausch, der die Verschlรผsselungsparameter finalisiert und die Authentizitรคt der server und mรถglicherweise der Kunde.

Clienthello

Der Client beginnt den Handshake durch Senden einer ClientHello-Nachricht an den serverDiese Nachricht enthรคlt die folgenden Informationen:

  • Eine Liste der unterstรผtzten Verschlรผsselungssammlungen und TLS-Versionen.
  • Ein Zufallswert (Client Random), der spรคter bei der Schlรผsselgenerierung verwendet wird.
  • Unterstรผtzte Durckstufen Methoden (obwohl die Komprimierung in neueren TLS-Versionen weitgehend veraltet ist).

ServerHallo

Das server antwortet mit einem ServerHallo-Nachricht. Diese Antwort enthรคlt:

  • Die ausgewรคhlte TLS-Version.
  • Die gewรคhlte Verschlรผsselungssammlung aus dem Vorschlag des Clients.
  • Ein anderer zufรคlliger Wert (server zufรคllig).

Zertifikats- und Schlรผsselaustausch

Das server sendet sein Zertifikat, das die servers รถffentlichen Schlรผssel zusammen mit der Zertifikatskette. Danach wird der server kann zusรคtzliche Schlรผsselaustauschparameter senden, wenn die gewรคhlte Verschlรผsselungssuite dies erfordert (zum Beispiel in Diffie-Hellman oder Elliptic Curve Diffie-Hellman-Chiffren).

Der Kunde รผberprรผft die serverund stellen Sie sicher, dass das Zertifikat gรผltig und nicht abgelaufen ist und von einer vertrauenswรผrdigen Zertifizierungsstelle signiert wurde.

Client-Verifizierung und Pre-Master Secret

Nachdem der Kunde die server, generiert es ein Pre-Master-Secret und verschlรผsselt es mit dem serverDer รถffentliche Schlรผssel. Dieses verschlรผsselte Pre-Master-Geheimnis wird dann an den server.

Das server verwendet seinen privaten Schlรผssel, um das Pre-Master-Geheimnis zu entschlรผsseln, und beide Parteien leiten Sitzungsschlรผssel aus dem Pre-Master-Geheimnis, dem Client-Random und dem server zufรคllig.

Handshake-Abschluss

Sowohl der Kunde als auch server Senden Sie sich gegenseitig โ€žFertigโ€œ-Nachrichten, die mit den neu abgeleiteten Sitzungsschlรผsseln verschlรผsselt sind. Diese Nachrichten bestรคtigen, dass die vereinbarten Schlรผssel richtig funktionieren und dass keine Manipulationen stattgefunden haben.

Sobald diese Nachrichten erfolgreich ausgetauscht und รผberprรผft wurden, ist der Handshake abgeschlossen und die nachfolgende Kommunikation wird mit den Sitzungsschlรผsseln verschlรผsselt.

Wann findet ein TLS-Handshake statt?

Ein TLS-Handshake findet statt, wenn ein Client eine neue sichere Verbindung zu einem server รผber TLS. Hรคufige Szenarien sind:

  • Der Zugriff auf eine Website รผber HTTPS (HTTP รผber TLS).
  • Initiieren sichere E-Mail Kommunikation (wie etwa SMTPS, IMAPS oder POP3S).
  • Herstellen einer Verbindung zu sicheren Anwendungen, die fรผr die Verschlรผsselung TLS verwenden (zum Beispiel VPN-Tunnel oder sichern Datei รœberweisungen).

Der Handshake wird wiederholt, wenn eine neue Sitzung hergestellt wird oder eine TLS-Neuverhandlung ausgelรถst wird, um die kryptografischen Schlรผssel fรผr Verbindungen mit langer Laufzeit zu aktualisieren.

Beispiel fรผr einen TLS-Handshake

Nachfolgend finden Sie eine Schritt-fรผr-Schritt-Anleitung fรผr einen typischen HTTPS-Handshake (HTTP รผber TLS) zwischen einem Client und einem server.

Schritt 1: Client fordert sichere Seite an

Der Webbrowser eines Benutzers initiiert eine sichere Verbindung, indem er eine ClientHello-Nachricht an den server bei โ€žexample.comโ€œ. Die ClientHello-Nachricht ist Teil des TLS-Handshake-Protokolls und enthรคlt mehrere wichtige Informationen:

  • Unterstรผtzte Protokollversion(en)Der Client schlรคgt eine oder mehrere Versionen von TLS vor (z. B. TLS 1.2, TLS 1.3), die er verwenden kann.
  • Client zufรคllig. Ein 32-Byte Vom Client generierter Zufallswert, der spรคter bei der Schlรผsselableitung verwendet wird.
  • Sitzungs-ID oder Sitzungsticket. Wenn der Client sich vor kurzem mit demselben server und รผber ein gรผltiges Sitzungsticket oder eine gรผltige Sitzungs-ID verfรผgt, bietet es mรถglicherweise an, die Wiederaufnahme der Sitzung anzufordern, wodurch einige Handshake-Schritte รผbersprungen oder verkรผrzt werden kรถnnen.
  • Verschlรผsselungssammlungen. Diese Suiten sind eine Liste kryptografischer Algorithmen, die der Client unterstรผtzt. Jede Cipher Suite gibt einen Schlรผsselaustauschmechanismus an (z. B. RSA, ECDHE), einen Verschlรผsselungsalgorithmus (z. B. AES) und einen Nachrichtenauthentifizierungscode oder Authentifizierungs-Tag-Algorithmus (z. B. SHA256).
  • ErweiterungsoptionenModerne TLS-Implementierungen umfassen verschiedene Erweiterungen wie server Namensanzeige (SNI), das die hostname der Client versucht zu erreichen. Zusรคtzliche Erweiterungen kรถnnen auf unterstรผtzte elliptische Kurven, Signaturalgorithmen und andere Parameter hinweisen, die die Sicherheit oder Leistung verbessern.

Nach Erhalt dieses ClientHallo, der server prรผft die vorgeschlagenen Verschlรผsselungssammlungen und TLS-Versionen, um festzustellen, ob sie unterstรผtzt werden. Der TLS-Handshake wird nur fortgesetzt, wenn server findet mindestens einen kompatiblen Parametersatz.

Schritt 2: Server Reagiert

Nach der Verarbeitung des ClientHello, der server antwortet mit einem ServerHallo-Nachricht. Sie enthรคlt mehrere Schlรผsselelemente:

  • Ausgewรคhlte Protokollversiondem โ€žVermischten Geschmackโ€œ. Seine server wรคhlt eine Version von TLS (z. B. TLS 1.2), die sowohl Client als auch server unterstรผtzen.
  • Server zufรคlligEin weiterer 32-Byte-Zufallswert, generiert durch server, wird mit dem Client-Random verwendet, um gemeinsame Schlรผssel abzuleiten.
  • Auswahl der Verschlรผsselungssammlung. Aus der Liste des Kunden wird der server wรคhlt eine einzelne Verschlรผsselungssuite aus, die es unterstรผtzt. Beispielsweise kรถnnte es einen ECDHE_RSA-Schlรผsselaustausch, AES_128_GCM-Verschlรผsselung und SHA256 fรผr die Nachrichtenauthentifizierung wรคhlen.
  • Sitzungs-ID oder neues Sitzungsticket. Wenn der server unterstรผtzt die Wiederaufnahme von Sitzungen; es kann die vom Client vorgeschlagene Sitzungs-ID akzeptieren oder eine neue bereitstellen.
  • Erweiterungsoptionendem โ€žVermischten Geschmackโ€œ. Seine server enthรคlt relevante Erweiterungsantworten und gibt alle spezifischen Parameter oder Einschrรคnkungen an.

Nach dem ServerHallo, der server sendet normalerweise zusรคtzliche Handshake-Nachrichten:

  • Zertifikatdem โ€žVermischten Geschmackโ€œ. Seine server รผbertrรคgt seine Zertifikatskette, die sein Endentitรคtszertifikat enthรคlt (das eigentliche server Zertifikat) und alle Zwischenzertifikate, die fรผr die Verknรผpfung mit einer Stammzertifizierungsstelle (CA) erforderlich sind.
  • Server Schlรผsselaustausch. Abhรคngig von der gewรคhlten Verschlรผsselungssuite, server stellt Schlรผsselaustauschparameter bereit (z. B. einen flรผchtigen รถffentlichen Diffie-Hellman-Schlรผssel), die der Client zum Generieren eines gemeinsamen Geheimnisses verwendet.
  • Zertifikatsanforderung (optional). Wenn der server erfordert eine Client-Authentifizierung, fordert in dieser Phase ein Client-Zertifikat an. Dies kommt beim normalen Surfen im Internet weniger hรคufig vor, kommt jedoch hรคufiger in Umgebungen vor, die gegenseitiges TLS erfordern.

Schritt 3: Zertifikatsvalidierung

Der Kunde prรผft die server, um sicherzustellen, dass die Verbindung tatsรคchlich mit dem beabsichtigten Host und nicht mit einem Betrรผger besteht:

  • รœberprรผfung der ZertifikatsketteDer Kunde รผberprรผft, ob die serverDas Zertifikat wurde von einer vertrauenswรผrdigen Zertifizierungsstelle ausgestellt und signiert. Der Browser oder Betriebssystem verwaltet einen Speicher vertrauenswรผrdiger Stammzertifikate. Der Browser prรผft auch Zwischenzertifikate, um eine gรผltige Vertrauenskette bis zu einer anerkannten Stammzertifizierungsstelle zu bilden.
  • Ablauf und GรผltigkeitDer Client รผberprรผft die โ€žNicht vorโ€œ- und โ€žNicht nachโ€œ-Daten des Zertifikats, um zu bestรคtigen, dass das Zertifikat aktuell gรผltig ist.
  • Domรคnennamen-Abgleich. Der Client bestรคtigt, dass der im Zertifikat aufgefรผhrte Domรคnenname (รผblicherweise im Feld โ€žAlternativer Antragstellernameโ€œ zu finden) mit โ€žexample.comโ€œ oder der angeforderten Domรคne รผbereinstimmt.
  • WiderrufsprรผfungDer Client kann die Zertifikatsperrliste (CRL) oder das Online Certificate Status Protocol (OCSP) verwenden, um festzustellen, ob das Zertifikat oder ein Zwischenzertifikat widerrufen wurde.

Wenn ein Teil des Validierungsprozesses fehlschlรคgt โ€“ beispielsweise aufgrund einer ungรผltigen Signatur, eines abgelaufenen Zertifikats oder eines nicht รผbereinstimmenden Domรคnennamens โ€“, beendet der Client normalerweise die Verbindung oder zeigt dem Benutzer eine Warnung an.

Schritt 4: Schlรผsselaustausch und Sitzungsschlรผsselgenerierung

Sobald der Kunde die serverNachdem der Client das Zertifikat des Unternehmens erhalten hat (und optional sein eigenes Zertifikat gesendet hat, falls angefordert), fรคhrt er mit dem Schlรผsselaustausch fort:

  • Client-Schlรผsselaustausch. Wenn ein RSA-Schlรผsselaustausch verwendet wird, generiert der Client eine Vor-Master-Geheimnis und verschlรผsselt es mit dem serverDer รถffentliche Schlรผssel (erhalten vom server Zertifikat). Wenn eine ECDHE- oder DHE-Chiffre-Suite verwendet wird, stellt der Client auch seinen eigenen flรผchtigen รถffentlichen Schlรผssel fรผr Diffie-Hellman-Berechnungen bereit.
  • Entschlรผsselung oder gemeinsame Schlรผsselberechnungdem โ€žVermischten Geschmackโ€œ. Seine server entschlรผsselt das Pre-Master-Secret mit seinem privaten Schlรผssel oder kombiniert im Fall von Diffie-Hellman/ECDHE die Daten des Clients und server's รถffentliche Schlรผssel, um ein gemeinsames Geheimnis zu berechnen.
  • Ableitung des Hauptgeheimnisses. Mithilfe des Pre-Master-Secrets (oder DH-Shared-Secrets) kรถnnen der Client und server beide leiten ein Master-Secret ab. Diese Ableitung beinhaltet auch den Client-Zufalls- und server zufรคllig. Pseudozufallsfunktionen (wie die in TLS 1.2 oder das โ€žHandshake Secretโ€œ in TLS 1.3) werden verwendet, um eine starke kryptografische Zufรคlligkeit sicherzustellen.
  • Erstellen eines Sitzungsschlรผssels. Aus dem Master Secret werden der Client und server Generieren Sie separate symmetrische Schlรผssel zum Verschlรผsseln ausgehender Daten, Entschlรผsseln eingehender Daten und รœberprรผfen der Nachrichtenintegritรคt. Diese Sitzungsschlรผssel werden normalerweise so ausgehandelt, dass sie flรผchtig sind (insbesondere bei ECDHE-basierten Chiffren), was Folgendes bietet: Vorwรคrtsgeheimnis.

Schritt 5: Sichere Datenรผbertragung

Nachdem beide Seiten die Sitzungsschlรผssel abgeleitet haben, server Austausch- Fertig Objekte Mitteilungen:

  • Fertige Nachrichten. Jede Seite berechnet einen kryptografischen Hash aller bisher gesendeten Handshake-Nachrichten (das Handshake-Transkript) und verschlรผsselt ihn mit den neu erstellten Sitzungsschlรผsseln. Diese โ€žFertigโ€œ-Nachrichten bestรคtigen, dass beide Parteien denselben Handshake-Status haben und dass keine Manipulation stattgefunden hat.
  • Handshake-BestรคtigungDer Kunde und server Bestรคtigen Sie den Empfang der jeweiligen Fertig-Nachricht. Wenn die Hashes รผbereinstimmen, bedeutet dies, dass der Handshake erfolgreich und sicher abgeschlossen wurde.
  • Verschlรผsselte AnwendungsdatenNachfolgende Daten โ€“ wie HTML Dateien, Bilder oder andere Inhalte auf Anwendungsebene โ€“ werden mit dem vereinbarten symmetrischen Schlรผssel verschlรผsselt. Die Verschlรผsselung gewรคhrleistet Vertraulichkeit, wรคhrend die kryptografische Hash- oder MAC (je nach Verschlรผsselungssuite) stellt die Integritรคt sicher.
  • Verbindungspersistenz und Sitzungswiederaufnahme. Wenn eine der beiden Seiten die Wiederaufnahme von TLS-Sitzungen unterstรผtzt, kรถnnen sie das ausgehandelte Hauptgeheimnis fรผr eine zukรผnftige Verbindung wiederverwenden. Dadurch wird der Aufwand fรผr die erneute Durchfรผhrung eines vollstรคndigen Handshakes reduziert.

Sobald die Handshake-Phase abgeschlossen ist, werden der Browser und server รผber einen sicheren Kanal kommunizieren. Browser zeigen in der Adressleiste normalerweise ein Schlosssymbol oder einen รคhnlichen Indikator an, um anzuzeigen, dass die Verbindung mit TLS verschlรผsselt und authentifiziert ist.

Warum sind TLS-Handshakes wichtig?

Ein TLS-Handshake bietet eine Methode zum Aufbau sicherer Kommunikation in Netzwerken, die anfรคllig fรผr Abhรถren oder Manipulation sein kรถnnen.

 Ein erfolgreicher Handshake bietet mehrere Vorteile:

  • Authentifizierung. Dem Kunden wird zugesichert, serverIdentitรคt, Verhinderung Man-in-the-Middle-Angriffe.
  • Vertraulichkeit. Der gesamte Datenverkehr nach dem Handshake wird verschlรผsselt, um sicherzustellen, dass keine unbefugten Parteien die Daten lesen kรถnnen.
  • Datenintegritรคt. Durch die Nachrichtenauthentifizierung wird sichergestellt, dass รผbertragene Daten wรคhrend der รœbertragung nicht verรคndert wurden.

Der Handshake-Prozess etabliert durch die Verwendung kryptografischer Algorithmen und Zertifikate eine robuste Vertrauensebene, die Informationen wรคhrend der รœbertragung schรผtzt.

Was passiert, wenn ein TLS-Handshake fehlschlรคgt?

Ein fehlgeschlagener TLS-Handshake fรผhrt dazu, dass keine sichere Verbindung hergestellt werden kann. Die Verbindung wird hรคufig beendet und Benutzer erhalten mรถglicherweise Fehlermeldungen wie โ€žSSL / TLS Handshake fehlgeschlagenโ€œ oder โ€žEs konnte keine sichere Verbindung hergestellt werden.โ€œ

Ein Fehler tritt auf, wenn Probleme wie inkompatible TLS-Versionen, ungรผltige Zertifikate, abgelaufene Zertifikate oder falsche Systemuhren eine erfolgreiche Aushandlung verhindern.

Wie behebt man einen TLS-Handshake?

Systemadministratoren und Endbenutzer kรถnnen Handshake-Fehler beheben, indem sie die Grundursachen beheben:

  • Aktualisieren oder installieren Sie gรผltige Zertifikate. Sie mรผssen abgelaufene oder ungรผltige Zertifikate ersetzen. Hosting-Anbieter und -Administratoren sollten sicherstellen, dass Zertifikate von vertrauenswรผrdigen Zertifizierungsstellen signiert sind und auf dem neuesten Stand bleiben.
  • รœberprรผfen Sie die Konfiguration und die unterstรผtzten Protokolle. Sicherstellen, dass sowohl Kunde als auch server Unterstรผtzung der gleichen TLS-Versionen und Verschlรผsselungssammlungen ist entscheidend. Durch die Deaktivierung alter Protokolle wie SSLv3 oder TLS 1.0 werden bekannte Schwachstellen und verhindert Handshake-Fehler im Zusammenhang mit veralteten Verschlรผsselungsmethoden.
  • Systemuhren synchronisieren. Genaue Systemuhren sind wichtig fรผr die Validierung der Ablauf- und Gรผltigkeitszeiten von Zertifikaten. server oder ein Client mit falscher Zeiteinstellung kann ansonsten gรผltige Zertifikate ablehnen.
  • รœberprรผfen von CA-Truststores. Das Betriebssystem oder die Anwendung des Clients verwaltet eine Liste vertrauenswรผrdiger Zertifizierungsstellen. Durch die รœberprรผfung, ob die entsprechende Stamm- oder Zwischenzertifizierungsstelle vorhanden und nicht widerrufen ist, kรถnnen Handshake-Fehler vermieden werden.
  • Kontrolliere server KonfigurationFalsch konfiguriert servers (zum Beispiel falsche Cipher Suite-Prioritรคten oder unvollstรคndige Zertifikatsketten) fรผhren hรคufig zu Handshake-Problemen. server Protokolle und Konfigurationen helfen dabei, die Nichtรผbereinstimmung zu lokalisieren und ermรถglichen eine schnelle Lรถsung.

Was ist der Unterschied zwischen SSL- und TLS-Handshake?

Der Begriff โ€žSSL-Handshakeโ€œ bezieht sich auf den Handshake-Prozess, der vom Sichere Sockets Layer (SSL) Protokoll, das ein frรผherer Standard zum Verschlรผsseln und Sichern von Daten war. Der TLS-Handshake ist die moderne Weiterentwicklung von SSL und bietet stรคrkere SicherheitsmaรŸnahmen und aktualisierte kryptografische Algorithmen.

Obwohl die Arbeitsablรคufe รคhnlich sind, brachte TLS gegenรผber SSL Verbesserungen mit sich, darunter erweiterte Verschlรผsselungssammlungen, eine bessere Zertifikatsverwaltung und robustere kryptografische Mechanismen. SSL wurde aufgrund bekannter Schwachstellen verworfen und die meisten modernen Systeme verwenden TLS fรผr die sichere Kommunikation.

In vielen Referenzen wird zur Beschreibung des sicheren Handshakes immer noch โ€žSSLโ€œ verwendet, selbst wenn TLS im Hintergrund verwendet wird. In aktuellen Implementierungen lautet die treffendere Bezeichnung jedoch โ€žTLS-Handshakeโ€œ. Das Grundprinzip bleibt dasselbe: Ein Handshake-Prozess verhandelt Sicherheitsparameter, tauscht Zertifikate aus und erstellt gemeinsame Schlรผssel fรผr die verschlรผsselte Kommunikation.


Nikola
Kostisch
Nikola ist ein erfahrener Autor mit einer Leidenschaft fรผr alles, was mit Hightech zu tun hat. Nach seinem Abschluss in Journalismus und Politikwissenschaft arbeitete er in der Telekommunikations- und Online-Banking-Branche. Schreibe gerade fรผr phoenixNAPEr ist darauf spezialisiert, komplexe Themen rund um die digitale Wirtschaft, den E-Commerce und die Informationstechnologie aufzuschlรผsseln.