it-swarm.com.de

Welche Rolle spielt die Taktsynchronisation bei der SSL-Kommunikation?

Wir haben kürzlich die WS Trust-Sicherheit über SSL für unsere Client/Server-Kommunikation implementiert. Unsere Anwendung wird von Tausenden unserer Kunden auf der ganzen Welt verwendet. Eines der Probleme, die wir in der Vergangenheit mit sicherer Kommunikation hatten, ist, dass Kunden mit nicht synchronisierten Uhren Schwierigkeiten haben, eine Verbindung herzustellen, was zu Kundenanrufen und Frustration führt. Leider besteht die Reaktion, die in der Vergangenheit verursacht wurde, darin, diese Prüfung einfach zu deaktivieren oder den akzeptablen Taktversatz einfach auf nahezu unendliche Beträge zu erhöhen.

Ich möchte nicht, dass die Sicherheit unseres Systems beeinträchtigt wird, und ich möchte auch keinen Zustrom von Beschwerden von Kunden auslösen, deren Uhren nicht eng mit der Zeit auf unseren Servern synchronisiert sind (die mit der Internetzeit synchronisiert sind). Damit ich verhindern kann, dass die Synchronisierungsprüfung effektiv deaktiviert wird, muss ich meinen Managern zunächst erklären können, warum dies eine schlechte Idee ist und warum die Vorteile der Uhrensynchronisierung die Kosten für Kundenbeschwerden oder Verwirrung überwiegen.

  1. Welche Rolle spielt die Taktsynchronisation bei der SSL-Kommunikation und welche Art von Sicherheitslücken bringt das Deaktivieren mit sich?
  2. Was wird normalerweise als maximal akzeptabler Bereich für die Taktsynchronisation in sicheren kundenorientierten Anwendungen angesehen?
24
mclark1129

In SSL werden Uhren für Zertifikatvalidierung verwendet. Der Client muss sicherstellen, dass er mit dem richtigen Server kommuniziert. Dafür wird der Client validieren das Zertifikat des Servers. Validierung bedeutet, viele Dinge zu überprüfen. Bei zwei handelt es sich um Uhren:

  • Das Serverzertifikat (und alle beteiligten CA-Zertifikate) muss die aktuelle Zeit in ihrem Gültigkeitszeitbereich enthalten. Jedes Zertifikat als notBefore und notAfter Felder; Die aktuelle Zeit muss zwischen diesen beiden Daten liegen.

  • Der Kunde soll den Widerrufsstatus jedes Zertifikats erhalten, indem er eine CRL (Certificate Revocation List) von den entsprechenden Ausstellern (dem CA). Eine CRL wird als akzeptabel angesehen, wenn sie (insbesondere) "nicht zu alt" ist: Wiederum hat die CRL ein thisUpdate Feld, das angibt, wann sie erstellt wurde, und ein nextUpdate Feld, das mehr- oder weniger dient als Ablaufdatum für die CRL.

Wenn die Uhr des Clients ausgeschaltet ist, werden eine oder beide dieser Funktionen unterbrochen. Beispielsweise wird das Zertifikat des Servers als "lange abgelaufen" oder "noch nicht verwendbar" betrachtet, was zur Ablehnung führt.

Wenn Sie akzeptieren, dass die Uhr des Clients ausgeschaltet ist, wird der Client geändert, um Datumsangaben in Zertifikaten und CRL nicht zu berücksichtigen. Die ultimative Konsequenz für die Sicherheit ist, dass wenn es einem Angreifer gelingt, den privaten Schlüssel eines Servers zu stehlen, dieser Angreifer sich für immer als dieser Server ausgeben kann. Der Widerrufspunkt besteht darin, eine überprüfte Methode zur Wiederherstellung eines solchen Kompromisses zu haben. und der Punkt des Ablaufs des Zertifikats besteht darin, zu verhindern, dass die CRL auf unbestimmte Zeit wächst. Wenn Clients Widerruf und/oder Ablauf ignorieren, ist die rohe Konsequenz, dass sobald ein Kompromiss eintritt, Sie für immer zum Scheitern verurteilt sind . Was normalerweise als eine schlechte Sache angesehen wird.

Dies ist ein Problem für Clients, nicht für den Server. Wenn Sie den Server betreiben, ist es die Aufgabe des Clients, nicht Ihre, Ihr Zertifikat ordnungsgemäß zu validieren. Wenn der Kunde wirklich darauf besteht, Dinge unsicher zu machen und verletzlich zu sein, können Sie dies nicht wirklich verhindern, zumindest nicht technisch (Sie können Dinge tun vertraglich: Wenn die Inkompetenz des Kunden einen Verstoß zulässt, kann der Kunde sollte dafür bezahlen).

Wenn die Clients mit Ihrem Server kommunizieren können, sind sie mit einem Netzwerk verbunden, was bedeutet, dass internetbasierte Zeitsynchronisation eine Möglichkeit ist. Das Erfordernis einer genauen Uhr ist für einige eingebettete Geräte eine Herausforderung, sollte jedoch nicht für vernetzte Computer (einschließlich Smartphones) gelten.

24
Thomas Pornin

Einfache Version (für Manager): Zeitsynchronisierungen können Wiederholungsangriffe verhindern. Ohne sie könnte jemand die zwischen Client und Server gesendeten Pakete aufzeichnen, entschlüsseln, Daten ändern und dann den Paketstrom erneut senden, und niemand wäre klüger. Da die Entschlüsselung jedoch einige Zeit in Anspruch nimmt, kann ein Zeitstempel (auf beiden Seiten validiert) anzeigen, dass es sich bei dem Stream um eine "Wiedergabe" handelt.

Vielleicht könnten Sie eine längere Zeitspanne für Ihr Unternehmen/Ihre Anwendung in Betracht ziehen? Anstelle eines schmalen Fensters können Sie einen Vorteil erzielen, indem Sie das Fenster erweitern. Dies müsste natürlich auf seine volle Auswirkung auf Ihre Systeme analysiert werden.

4
schroeder