it-swarm-eu.dev

Welche Sicherheitslücken können durch ein Wildcard-SSL-Zertifikat verursacht werden?

In einem Kommentar zu diese Antwort sagt AviD:

"Es gibt zahlreiche Sicherheitsprobleme mit Wildcard-SSL-Zertifikaten."

Also, was sind die Probleme? Ich verstehe, dass derselbe private Schlüssel in mehreren Kontexten verwendet wird, aber da ich alle meine Anwendungen unter demselben Hostnamen hosten könnte, sehe ich dies nicht als "neues" Problem, das durch Platzhalterzertifikate eingeführt wird.

46
user185

Ein "Platzhalterzertifikat" ist ein Zertifikat, das als möglichen Servernamen einen Namen enthält, der ein "*" - Zeichen enthält. Details finden Sie in RFC 2818, Abschnitt 3.1 . Fazit: Wenn das Serverzertifikat *.example.com Enthält, wird es von Clients als gültiges Zertifikat für jeden Server akzeptiert, dessen scheinbarer Name übereinstimmt dieser Name.

Im Zertifizierungsgeschäft für Websites gibt es vier Hauptakteure:

  • Der SSL-Server selbst.
  • Der Anbieter des Webbrowsers, den der Client verwenden wird.
  • Der menschliche Benutzer, der bis zu einem gewissen Grad steuert, was der Client-Browser tun wird.
  • Die Zertifizierungsstelle, die das Zertifikat an den Server ausgestellt hat.

Platzhalterzertifikate bedeuten keine zusätzlichen Sicherheitslücken für den SSL-Server. In der Tat hat der SSL-Server kein Interesse daran, sich ein eigenes Zertifikat anzusehen. Dieses Zertifikat dient den Kunden, um sie davon zu überzeugen, dass der im Zertifikat enthaltene öffentliche Schlüssel tatsächlich der öffentliche Schlüssel des echten SSL-Servers ist. Der SSL-Server weiß sein eigenes öffentliches/privates Schlüsselpaar und muss nicht davon überzeugt werden.

Der menschliche Benutzer hat keine Ahnung, was ein öffentlicher Schlüssel ist. Was er sieht, ist ein Vorhängeschlosssymbol und vor allem der vorgesehener Servername: das ist der Name rechts von "https://" Und vor dem nächsten "/ ". Der Webbrowser ist angenommen, um die technischen Details der Überprüfung der Richtigkeit des Namens, d. H. Der Überprüfung des Serverzertifikats, und der Überprüfung, ob der Name mit dem in dem Zertifikat geschriebenen übereinstimmt, zu verarbeiten. Wenn der Browser diesen Job nicht ausführt, wird er als schlampig angesehen und übernimmt nicht seine Rolle, was schwerwiegende kommerzielle Konsequenzen haben kann, möglicherweise sogar rechtliche. In ähnlicher Weise ist die Zertifizierungsstelle vertraglich verpflichtet, definierte Verfahren zur Identifizierung von SSL-Serverbesitzern zu befolgen, sodass gefälschte Zertifikate für Angreifer nur schwer erhältlich sind (der Vertrag besteht rekursiv zwischen der Zertifizierungsstelle und ihrer Über-Zertifizierungsstelle bis zur Stammzertifizierungsstelle, die selbst gebunden ist durch einen Pakt mit dem Betriebssystem oder dem Browserhersteller, der akzeptiert hat, den Stammzertifizierungsstellenschlüssel unter definierten Bedingungen in das Betriebssystem oder den Browser aufzunehmen).

Dies bedeutet, dass der Browser und der [~ # ~] ca [~ # ~] den Benutzer in der Praxis durch das verwöhnen müssen Überprüfungsprozess. Sie sind mehr oder weniger verpflichtet (gesetzlich oder noch strenger aus geschäftlichen Gründen), zu verhindern, dass der Benutzer durch gefälschte Websites betrogen wird, die legitim aussehen. Die Grenze zwischen dem Job des Benutzers und dem Browser-/CA-Job ist nicht klar definiert und hat sich historisch verschoben. In Days of Yore, ich meine vor ungefähr zehn Jahren, haben Browser nur die unformatierte URL ausgedruckt, und es war Sache des menschlichen Benutzers, den Servernamen darin zu finden. Dies führte dazu, dass gefälschte Site-Betreiber (d. H. "Phishing-Sites") URLs verwendeten, die technisch gültig, aber irreführend sind, wie diese:

https://www.Paypal.com:[email protected]/confirm.html

Da menschliche Benutzer menschlich sind und die meisten von ihnen von links nach rechts lesen (die reichsten und leichtgläubigsten Betrugsziele befinden sich immer noch in westlichen Ländern), beginnen sie links, siehe www.Paypal.com, Halten Sie am Doppelpunkt ("zu technisch") an und lassen Sie sich betrügen.

Als Reaktion darauf haben Browser-Anbieter anerkannt, dass die URL-Analysefähigkeiten menschlicher Benutzer nicht so gut sind, wie ursprünglich angenommen, und daher heben neuere Browser den Domain-Teil hervor. Im obigen Fall wäre dies xcvhjvb.com Und sicherlich nichts mit Paypal.com. Nun kommt der Teil, in dem Wildcard-Zertifikate das Spiel betreten. Wenn der Besitzer von xcvhjvb.com Ein Platzhalterzertifikat mit "*.xcvhjvb.com" Kauft, kann er eine Phishing-Site mit dem Namen einrichten:

https://Paypal-payment-interface-login-session.xcvhjvb.com/confirm.html

dies wird vom Browser akzeptiert (es entspricht dem Platzhalternamen) und fängt wahrscheinlich immer noch unachtsame Benutzer auf (und es gibt viele ...). Dieser Name könnte wurde vom Angreifer gekauft, ohne auf Platzhalter zurückzugreifen, aber dann hätten die CA-Mitarbeiter den Namen mit einem offensichtlichen betrügerischen Versuch gesehen (gute CA do eine menschliche Validierung jeder Anforderung von Zertifikaten oder zumindest Warnungen für Namen, die sehr lang sind und/oder bekannte Banknamen enthalten).

Daher Platzhalterzertifikate verringern die Wirksamkeit von Maßnahmen zur Eindämmung von Betrug auf der CA-Seite. Dies ist wie eine leere Signatur der Zertifizierungsstelle. Wenn Wildcard-basierte Phishing-Versuche häufiger auftreten, kann man davon ausgehen, dass eine oder mehrere der folgenden Maßnahmen ergriffen werden:

  • Browser markieren nur die Teile des Domainnamens, die mit Nicht-Platzhalter Elementen im Zertifikat übereinstimmen.
  • CA erfordert schwerere Unterlagen und Verträge für Wildcard-Zertifikate (und diese werden teurer).
  • Browser deaktivieren die Unterstützung für Platzhalterzertifikate insgesamt.

Ich gehe davon aus, dass alle drei Maßnahmen in den nächsten Jahren angewendet werden. Ich könnte völlig falsch liegen (das ist das Problem bei der Vorhersage der Zukunft), aber das ist immer noch mein Bauchgefühl.


Wir können auch darauf hinweisen, dass Platzhalterzertifikate nützlich sind, um dasselbe Schlüsselpaar zwischen verschiedenen Servern zu teilen Namen, was es wahrscheinlicher macht, dass der private Schlüssel zwischen verschiedenen Servern geteilt wird Maschinen. Das Reisen mit privaten Schlüsseln ist ein eigenständiges Sicherheitsrisiko. Je mehr ein privater Schlüssel herumwandert, desto weniger "privat" bleibt er.

35
Thomas Pornin

Es wird empfohlen, denselben privaten Schlüssel auf mehrere Server zu verteilen, die unterschiedliche Dienste bereitstellen: Bei ausgenutzten Sicherheitsproblemen in einem Dienst wird der für alles verwendete private Schlüssel angezeigt.

Es ist jedoch üblich, Platzhalterzertifikate zu verwenden, um vom Benutzer bereitgestellte Webinhalte in benutzerspezifischen Subdomänen zu isolieren und dieselbe Origin-Richtlinie zu nutzen. Der gleiche Ansatz wird üblicherweise zum Rendern nicht vertrauenswürdiger Portlets verwendet. Es ist Teil des Open Social "Standards".

An meinem Arbeitsplatz entwickeln wir eine Software, die eine offene soziale Implementierung enthält und das Wildcard-Setup verwendet. Kundeninstallationen wurden Penetrationstests unterzogen. Das Wildcard-Setup wurde nicht kritisiert.

18

Letztendlich sind viele der in diesen Antworten genannten Schwachstellen auf unterschiedliche Vertrauensniveaus zurückzuführen. Wenn Sie jedoch wissen, wie Platzhalterzertifikate funktionieren, können Sie diese Sicherheitsanfälligkeiten für bestimmte Anwendungsfälle verringern. Ich denke, dass eine detailliertere Erklärung den Nutzen dieser Frage und ihrer Antworten verbessern wird.

Sofern nicht alle Systeme in Ihrer Domäne dieselbe Vertrauensstufe haben, ist die Verwendung eines Platzhalterzertifikats zur Abdeckung aller von Ihnen kontrollierten Systeme eine schlechte Idee. Sie können jedoch DNS-Subdomänen als Segmentierungswerkzeug verwenden. Wie Platzhalter sagten, können Sie ein Platzhalterzertifikat auf einen bestimmten Namespace beschränken, da Platzhalter keine Subdomänen durchlaufen. Wenn Sie beispielsweise eine CDN-Farm hätten, könnten Sie nur *.cdn.example.com Platzhalter setzen. Dadurch werden Hosts in example.com Selbst (wie www.example.com) Getrennt, und Sie können ein separates Zertifikat für www.example.com Ausstellen.

Wie AviD von OWASP erwähnt hat: Interne Workstations, Entwicklungssysteme usw. gehören zu niedrigeren Vertrauensstufen. Hosts wie diese sollten sich jedoch ohnehin in ihrem eigenen internen Domänenbereich befinden (wie prv.example.com). Da Platzhalter keine Subdomains durchlaufen, kann ein *.example.com - Zertifikat nicht auf prv.example.com - Hosts angewendet werden. (Dies würde öffentliche und private Eigenschaften getrennt halten, trennt jedoch offensichtlich keine privaten Eigenschaften voneinander. Es könnten andere Platzhalter für Subdomänen verwendet werden, die geeigneten Vertrauensstufen zugeordnet sind.).

Während dieser eWeek-Artikel feststellt, dass der private Schlüssel von mehreren Hosts gemeinsam genutzt werden kann, diese SSLShopper-Gegenargumentation besagt, dass einige Aussteller (wie DigiCert) es Ihnen ermöglichen, separate private Schlüssel für jeden zu generieren Wildcard-Host. Dies verringert zwar die Nützlichkeit von Platzhalterzertifikaten, verringert jedoch definitiv das Problem der gemeinsam genutzten privaten Schlüssel und kann unter bestimmten Umständen hilfreich sein. Andernfalls werden in diesem Entrust-Artikel und dem Whitepaper PDF, auf das verwiesen wird bewährte Methoden für die Verwaltung privater Schlüssel bei Verwendung mit Platzhalterzertifikaten erläutert.

Schließlich wird auf ein Argument der Behörde zurückgegriffen ... Wenn Google verwendet Platzhalterzertifikate für einige ihrer Eigenschaften , dürfen sie nicht allgemein schlecht sein:

Qualys SSL Labs screenshot for youtube.com cert

:-)

9
Royce Williams

Im Idealfall sollte die Liste der Dienste, für die ein Zertifikat/Schlüssel verwendet werden kann, mit der Liste der Dienste übereinstimmen, für die das Zertifikat/der Schlüssel verwendet werden soll.

Nehmen wir an, Sie haben eine Domain example.com. Sie richten verschiedene Hostnamen unter dieser Domain ein: www.example.com catpictures.example.com users.example.com. Alle werden auf demselben Server gehostet, sodass Sie ein Zertifikat erhalten, das sie alle abdeckt.

Angenommen, Sie richten Secure.example.com auf einem höher gesicherten Server ein. Nehmen wir an, Sie erhalten ein separates Zertifikat für diesen Server.

Überlegen Sie nun, was passiert, wenn der private Schlüssel, der dem Zertifikat auf dem ersten Server entspricht, gestohlen wird.

Wenn es sich um ein Zertifikat für * .example.com (ein Platzhalterzertifikat) handelte, können die Angreifer es als sicheres.example.com ausgeben

Wenn es sich um ein Zertifikat für www.example.com catpictures.example.com und users.example.com handelt, können die Angreifer es nicht als sicheres Beispiel verwenden

4
Peter Green