en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

Delegierte Anmeldeinformationen für TLS

Beenden a TLS Verbindung erfordert die Verwendung des privaten Schlüssels eines Zertifikats. Daher muss der private Schlüssel auf jedem einzelnen Server gespeichert werden, der von einem Dienst verwendet wird. Der Schutz der Geheimhaltung dieses privaten Schlüssels ist für den reibungslosen Betrieb eines Public Key Infrastructure-Schemas von größter Bedeutung. Eine Entität, die im Besitz des privaten Schlüssels ist, kann für die verbleibende Gültigkeitsdauer des Zertifikats Man-in-the-Middle-Angriffe durchführen. Wenn ein Angreifer einen privaten Schlüssel kompromittiert, wird normalerweise das diesem Schlüssel zugeordnete Zertifikat widerrufen und ein neues ausgestellt. Für Unternehmen, die mehrere Server verwenden, wie Facebook oder Content Delivery Networks, sind wichtige Kompromisse, insbesondere bei Edge-Servern, nicht leicht zu erkennen und gefährden somit das gesamte Netzwerk. Delegierte Anmeldeinformationen ermöglichen Servern die Ausführung TLS Handshakes, während der private Schlüssel des Zertifikats an einem sicheren Ort gespeichert wird.

Delegierte Credentials sind digital signierte Datenstrukturen, die aus zwei Teilen bestehen: einem Gültigkeitsintervall und einem öffentlichen Schlüssel (zusammen mit dem zugehörigen Signaturalgorithmus). Sie dienen als „Vollmacht” für die Server, die angeben, dass sie autorisiert sind, beenden die TLS Verbindung. Der Prozess der Ausstellung von delegierten Berechtigungsnachweisen befindet sich derzeit in der Standardisierung und ist darin definiert IEFT-Entwurf. Der Entwurf definiert die Verwendung von delegierten Anmeldeinformationen wie folgt:
 
„Ein begrenzter Delegationsmechanismus, der es ermöglicht, TLS Peer, eigene Credentials im Rahmen eines von einer externen CA ausgestellten Zertifikats auszustellen. Diese Anmeldeinformationen ermöglichen es dem Empfänger der Delegierung nur, für Namen zu sprechen, die die CA autorisiert hat.“
Delegierte Anmeldeinformationen wurden mit dem Ziel entwickelt, die Sicherheit zu erhöhen. Daher besitzen sie bestimmte Eigenschaften, wie sie im IEFT-Entwurf definiert sind.
  • Die maximale Gültigkeitsdauer eines delegierten Ausweises beträgt sieben (7) Tage um die Gefährdung zu minimieren, wenn der private Schlüssel kompromittiert wird. Die kurze Gültigkeitsdauer bedeutet nicht, dass die Sicherheit der delegierten Anmeldeinformationen auf die leichte Schulter genommen werden sollte. Maßnahmen zum Schutz des privaten Schlüssels des End-Entity-Zertifikats sollten auch für den Schutz von DCs gelten. Dazu gehören unter anderem Dateisystemkontrollen, physische Sicherheit und Hardware-Sicherheitsmodule. Darüber hinaus sollten delegierte Anmeldeinformationen nur zwischen Parteien verwendet werden, die eine gewisse Vertrauensstellung miteinander teilen.
  • Die delegierten Anmeldeinformationen sind kryptographisch gebunden zum Endteilnehmerzertifikat. Konkret wird der private Schlüssel des End-Entity-Zertifikats verwendet, um die Signatur des DC über einen durch den Credential spezifizierten Algorithmus zu berechnen. Die Signatur bindet den DC effektiv an die Namen des End-Entity-Zertifikats.
  • Delegierte Anmeldeinformationen werden vom Client ausgestellt, was viel einfacher ist, als ein von einer Zertifizierungsstelle signiertes Zertifikat zu erstellen. Vom Client ausgestellte Zertifikate sind auch hilfreich, damit der Dienst auch bei Ausfallzeiten der Zertifizierungsstelle funktioniert. Außerdem können Organisationen mit Algorithmen experimentieren, die nicht offiziell von der Zertifizierungsstelle unterstützt werden, ohne die Sicherheit des End-Entity-Zertifikats zu gefährden. 
  • Delegierte Berechtigungsnachweise haben per Definition kurze Gültigkeitsdauern. Beim Festlegen der Lebensdauer delegierter Anmeldeinformationen müssen Server den Zeitversatz des Clients berücksichtigen, um die Ablehnung von Zertifikaten zu vermeiden. Die Client-Uhrzeitverschiebung ist auch für das Originalzertifikat wichtig, aber entscheidend für den kurzlebigen delegierten privaten Schlüssel. Sowohl am Anfang als auch am Ende des Gültigkeitszeitraums sollte die Client-Uhrzeitverschiebung berücksichtigt werden.
  • Es gibt keinen Widerrufsmechanismus für delegierte Anmeldeinformationen. Sie verlieren nach Ablauf der Gültigkeitsdauer ihre Gültigkeit. Das Widerrufen des privaten Schlüssels des End-Entity-Zertifikats (das zum Signieren der delegierten Anmeldeinformationen verwendet wird) widerruft jedoch implizit die delegierten Anmeldeinformationen. 
  • Delegierte Anmeldeinformationen sind für die Verwendung in TLS 1.3 oder später. Es gibt eine bekannte Sicherheitslücke, wenn TLS 1.2-Server unterstützen den RSA-Schlüsselaustausch und ermöglichen das Fälschen einer RSA-Signatur über eine beliebige Nachricht. Angenommen, ein Angreifer ist in der Lage, eine Signatur zu fälschen. In diesem Fall können sie gefälschte delegierte Anmeldeinformationen für die gesamte Gültigkeitsdauer des End-Entity-Zertifikats erstellen. Diese Sicherheitsanfälligkeit ist in Implementierungen von . nicht vorhanden TLS 1.3 oder höher. Außerdem betrifft die Sicherheitsanfälligkeit keine Zertifikate mit elliptischer Kurvenkryptografie, die SSL.com bietet. 
  • Unternehmen können vorhandene APIs zur automatisierten Ausstellung wie ACME verwenden, um delegierte Anmeldeinformationen bereitzustellen. In diesem Fall werden nur die Algorithmen verwendet, die von der CA unterstützt werden, aber diese Vorgehensweise verringert die Möglichkeit von Schlüsselkompromittierungen. SSL.com befürwortet diese Praxis. 
  • Delegierte Anmeldeinformationen können nicht in mehreren Kontexten wiederverwendet werden. Die ausstellenden Parteien berechnen die Signatur unter Verwendung einer Kontextzeichenfolge, die für die beabsichtigte Rolle (Client oder Server) eindeutig ist, wodurch die Verwendung derselben delegierten Anmeldeinformationen für die Client- und Serverauthentifizierung unmöglich wird. 
SSL.com unterstützt die Verwendung von delegierten Anmeldeinformationen für alle Clients. Die Ausstellung von Zertifikaten mit delegierten Anmeldeinformationen kann durch die Verwendung von APIs für die Automatisierung unter Verwendung des ACME-Protokolls erfolgen. Seit SSL.com nutzt ECDSA, um die PKI angeboten Clients sind von unseren Clients ausgestellte delegierte Anmeldeinformationen nicht anfällig für Signaturfälschungsangriffe, wie oben beschrieben. 

Verwandte Artikel

Abonnieren Sie den Newsletter von SSL.com

Was ist SSL /TLS?

anschauen

Abonnieren Sie den Newsletter von SSL.com

Verpassen Sie keine neuen Artikel und Updates von SSL.com