Frage:
Besteht ein Risiko für ein Unternehmen, das ein freigegebenes Zertifikat verwendet?
trAnwhiz
2016-07-07 17:54:45 UTC
view on stackexchange narkive permalink

Ich habe das Zertifikat meiner Bank-Website überprüft und festgestellt, dass es für mehrere Websites ausgestellt wurde und der Domain-Name der Bank nur unter vielen anderen Domains im Feld "Alternative Namen" aufgeführt ist.

Wird dies berücksichtigt? eine schlechte Praxis? Welchen Risiken sind ihre Kunden ausgesetzt? (Mann in der Mitte? Identitätswechsel?)

SSL Labs screenshot

Dies scheint eine schlechte Praxis zu sein, da alle diese anderen Parteien denselben privaten Schlüssel haben, wenn sie auch dieses Zertifikat verwenden.Dies bedeutet, dass ein Kompromiss mit einer anderen Site dazu führen kann, dass Ihr SSL-Verkehr nicht mehr sicher ist.
Eine Bank, die CDN von Drittanbietern und Drittländern mit SSL-Interception verwendet ... Ich würde das Konto lieber schließen.
"Blick auf meine Bank-Website ..." - Welcher * Teil * der Website ist das?Ist es nur die statische Begrüßung, wir sind die Bank mit den vielen Bildern von glücklichen Mitarbeitern und Kunden auf unserer Website, oder ist es der Teil, der das Protokoll enthält?in Form und vielleicht das Zeug dahinter?
Ich glaube nicht, dass sich viele Antwortende die Mühe gemacht haben, den Inhalt der von Ihnen abgefragten Website zu überprüfen.Dies sind nur die Informationsseiten, das Marketing usw. der Bank. Sobald Sie tatsächlich versuchen, sich beim eigentlichen Bankdienst der Bank anzumelden, werden Sie zu einer anderen Domain weitergeleitet, die über ein EV-Zertifikat verfügt und nicht über Incapsula weiterleitet.Daran ist nichts Ungewöhnliches oder zu Besorgniserregendes.
@JimmyB enthält auch dann, wenn die Begrüßungsseite kein Anmeldeformular enthält, mit ziemlicher Sicherheit einen Link zum Anmeldeformular.Ein Angreifer kann viel Schaden anrichten, indem er diesen Link ändert.
Sechs antworten:
#1
+50
techraf
2016-07-07 18:16:40 UTC
view on stackexchange narkive permalink

Es handelt sich um ein Zertifikat eines Content Delivery Network - eines US-amerikanischen Unternehmens Incapsula Inc. -, das Ihre gesamte Kommunikation mit der Bank abfängt. Das Zertifikat selbst stellt kein direktes Risiko für die Kundendaten dar, aber:

Wird dies als schlechte Vorgehensweise angesehen?

Im Gegensatz zum anderen Antworten, ich würde sagen, es ist nicht normal und die Situation weist auf ein gewisses Maß an Inkompetenz auf der Seite der Bank hin.

  1. Laut Incapsula Preispläne, Ihre Bank verwendet möglicherweise 59 USD / Monat, während das Unternehmen benutzerdefiniertes SSL für 299 USD / Monat (Funktion "Unterstützt benutzerdefinierte SSL-Zertifikate") und einen echten Plan für Unternehmen anbietet.

  2. Auch wenn die Bank mehr an CDN zahlt, verwendet die Bank Funktionen für professionelle Blogs und nicht die Funktionen, die ihr Plan / ihre Vereinbarung bietet.

  3. Ihre Bank verstößt möglicherweise gegen Datenschutzgesetze in Ihrem Land, indem sie ein Unternehmen aus einem anderen Land unter einem anderen Gesetzgeber die personenbezogenen Daten von Kunden verarbeiten lässt.

  4. ol>

    Welchen Risiken sind ihre Kunden ausgesetzt? (Mann in der Mitte? Identitätswechsel?)

    Die Daten werden zwischen Ihrem Browser und dem Endpunkt des CDN verschlüsselt. Der private Schlüssel wird (hoffentlich) nur auf den Servern von CDN gespeichert, sodass kein Risiko besteht, dass andere Unternehmen aus der Liste sich als Bank ausgeben.

    Solange die Sicherheitsstandards für eine Verbindung zwischen CDN und der Bank eingehalten werden ist das MitM auch technisch nicht möglich.

Ich möchte darauf hinweisen, dass der Sinn eines CDN darin besteht, den Datenverkehr von vielen verteilten Standorten zu Server zu übertragen, um die Leistung zu verbessern und / oder Angriffe zu vermeiden.Leider bedeutet dies für https, die Schlüssel zum Königreich weit und breit zu verbreiten.Die Verwendung eines separaten Zertifikats für jeden Kunden würde weniger offensichtlich machen, was vor sich geht, aber die Sicherheit nicht wirklich verbessern.
Ich möchte darauf hinweisen, dass das CDN im Gegensatz zu Ihrem letzten Punkt technisch jede Verbindung zur Bank * abmischt *.Sie tun (wahrscheinlich) nicht böswillig etwas Schlechtes, aber es ist ein Risiko und erhöht die Gefährdung sensibler Bankdaten / -ausweise, da ein Kompromiss bei * entweder * der Bank oder dem CDN vertrauliche Finanzdaten Angreifern zugänglich machen kann.Was (hoffentlich) unmöglich ist, ist ein zusätzliches MitM zwischen Kunde und CDN oder CDN und Bank, aber Sie können nicht vergessen, dass das CDN selbst per Definition ein MitM ist.
Ja, es ist ein Risiko (noch größer, da sich das CDN anscheinend in einem anderen Gesetzgeber befindet, den ich erwähnt habe), aber es ist nicht das Risiko, das sich aus der Tatsache ergibt, dass das Zertifikat zwischen verschiedenen Domänen geteilt wird, was die Frage war.Wenn die Bank ein eigenes Zertifikat verwenden würde, würde dies die Situation nicht ändern.
#2
+5
Bubble Hacker
2016-07-07 18:11:59 UTC
view on stackexchange narkive permalink

Beachten Sie incapsula.com im Betreff. Incapsula ist ein Unternehmen, das Webanwendungssicherheit bietet, die WAF, DDOS-Schutz und einige weitere Dienste umfasst.

Ich vermute, dass die Website Ihrer Bank tatsächlich über ihren Server und so weiter vertreten ist sind all diese anderen Seiten. Dieser Server stellt auf allen diesen Sites dasselbe Zertifikat aus, da alle tatsächlich über denselben Server übertragen werden.

Hier besteht kein Grund zur Sorge.

Die Antwort von techraf zeigt, dass die ersten beiden Absätze zwar sehr richtig sein können, die Schlussfolgerung im dritten jedoch verfrüht sein kann.
#3
+2
gowenfawr
2016-07-07 18:07:53 UTC
view on stackexchange narkive permalink

Dies kann normal sein.

Banken konsolidieren, kaufen, vermarkten häufig und tun alle möglichen Dinge, die bedeuten, dass sie auf mehr als einen Namen antworten . Es ist nicht ungewöhnlich, dass eine Bank über zahlreiche SAN-Einträge verfügt, damit alle ihre unterschiedlichen Kunden auf ihre Website gelangen können, selbst wenn sie Kunde einer Bank sind, die von einer von einer Bank gekauften Bank gekauft wurde von einer Bank gekauft, die von einer Bank gekauft wurde, die sie erworben haben.

Möglicherweise möchten Sie überprüfen, ob die anderen aufgeführten Namen dieselbe IP-Adresse haben und / oder von Websites bereitgestellt werden, die dieselbe verwenden Zertifikat. Wenn diese Domänen tatsächlich einen gemeinsamen Eigentümer haben, ist dies möglicherweise eine normale Vorgehensweise.

Aus Sicherheitsgründen ist es möglicherweise schlimmer, wenn der private Schlüssel an zahlreiche Server weitergegeben wird , zahlreiche Admins - aber nicht definitiv . Sie wissen nicht genug darüber, was tatsächlich hinter den Kulissen passiert, um es zu sagen.

Schau dir diesen Screenshot an.Es enthält viele nicht bankbezogene Domainnamen wie nescafemountainwash.com.my.Ihre SAN-Erklärung macht keinen Sinn.
Ich persönlich habe nie verstanden, warum SSL nur eine Schicht kryptografischer Sicherheit bietet.In diesem Fall wäre es ideal, wenn der SSL-Inhalt zweimal verschlüsselt würde: Eine Schicht wird vom Proxy-Host entfernt, während eine zweite Schicht von der Bank entfernt wird.Dies würde es dem Proxy ermöglichen, den Datenverkehr zu verarbeiten, ohne zu wissen, was er enthält.Dies würde es auch den beiden Parteien, die "letztendlich kommunizieren" (der Bank und ihrem Kunden) ermöglichen, sich trotz des Vertreters gegenseitig zu erkennen.
@MikeRobinson, Hier finden Sie einige Antworten (für und wider) auf diese Idee ([... hat jemand PGP oder AES verwendet, um die tatsächlichen Daten in SSL zu verschlüsseln?] (Http://security.stackexchange.com/q/46529/).3365))
Ja ich sehe es.Es hat mich immer ein bisschen überrascht, dass das SSL-Protokoll und seine verschiedenen Nachfolger diese Idee nie umgesetzt haben.Die vom Protokoll bereitgestellte Verschlüsselung ist äußerst wünschenswert, da sie für diejenigen, die kommunizieren, * transparent * ist.Es wird jedoch nur direkt eine einzelne Verschlüsselungsebene bereitgestellt.In der realen Welt steckt man manchmal einen versiegelten Umschlag in einen anderen versiegelten Umschlag ...
#4
+2
usr-local-ΕΨΗΕΛΩΝ
2016-07-07 20:35:50 UTC
view on stackexchange narkive permalink

Nicht unbedingt ein konkretes Sicherheitsrisiko, sobald Sie (der IT-Administrator) auf die neuen Risiken vorbereitet sind.

Verstärkte Verfahren

Wenn Sie für viele ein einziges Zertifikat haben Domänen ist es ein einzelner Fehlerpunkt und das schwächste Kettenblatt. Sie müssen teure IT-Verfahren erzwingen, um den privaten Schlüssel "nur Augen" oder besser "nur HTTPS-Server" zu erhalten. Die Kompromittierung des einzelnen Schlüssels wirkt sich auf alle Dienste gleichzeitig aus. Ihr gesamtes Unternehmen hängt von einer einzigen 4096-Bit-langen Nummer ab.

Mögliche Verfügbarkeitsprobleme

Wenn ein einzelner Schlüssel von mehreren Diensten in einem CDN gemeinsam genutzt wird, wird durch seinen Kompromiss das gesamte CDN heruntergefahren für den Zeitraum der Erneuerung des Schlüssels. Das Hinzufügen einer neuen Domäne für den Dienst umfasst das erneute Ausstellen des Zertifikats mit der damit verbundenen Ausfallzeit.

Lastausgleich effektiv

Die Verwendung solcher gemeinsam genutzten Zertifikate bietet einen Vorteil. In einem CDN können Sie effektiv HTTPS-Proxys einrichten. Dies ist eine weit verbreitete Methode und bietet große Leistungsvorteile.

Grundsätzlich hostet Ihre DMZ eine Reihe von Reverse -Proxy-Servern mit Lastenausgleich, die HTTPS-Datenverkehr empfangen, entschlüsseln und weiterleiten HTTP-Verkehr (Hinweis, kein S) zu den realen Servern innerhalb des CDN-Netzwerks. Dies erfordert eine starke Einrichtung des internen Netzwerks, um die Paketsicherheit zu gewährleisten. Es gibt jedoch Fachleute, die daran arbeiten. Denken Sie daran, dass der unverschlüsselte Datenverkehr nur innerhalb einer Vertrauenszone fließt.

Warum also? Lastverteilung? Denn wenn Ihr CDN 1000 Sites hostet und einige von ihnen einen Anstieg des Datenverkehrs verzeichnen, müssen Sie keine Maschinen für sie bereitstellen. Sie können die Proxys als Round-Robin arbeiten lassen.

Kein SNI

Es gibt einen technischen Grund für Zertifikate mit mehreren Aliasing, und das CDN möchte nicht erfordern SNI (Server Name Identification) von Clients. Insbesondere in der Finanz- / Unternehmenswelt sind die Browser einiger Benutzer möglicherweise zu alt, um SNI zu unterstützen.

Das Bereitstellen eines neuen Zertifikats für jeden neuen Dienst mit einem anderen privaten Schlüssel ist eine gute Sicherheitspraxis.

#5
+1
ZigZag_IL
2016-07-13 10:11:03 UTC
view on stackexchange narkive permalink

Ich bin beim Imperva Incapsula-Team.

Es scheint viel Verwirrung zu geben, daher möchte ich auf einige Fakten hinweisen:

  1. Die überwiegende Mehrheit aller Websites verwendet ein CDN.
  2. Wir sind PCI- und SOC2-zertifiziert. Alle Datenverarbeitungs-, Zugriffs- und sonstigen Compliance-Probleme werden streng reguliert, geprüft und protokolliert.
  3. Wir haben einige der größten Banken, Finanz- und Gesundheitsorganisationen sowie Regierungen, die unseren Service nutzen und uns ihre Zertifikate anvertrauen.
  4. Ehrlich gesagt gehören die IT-Abteilungen der Banken zu den am meisten untersuchten in der EU In der IT-Branche können Sie darauf vertrauen, dass sie die Best Practices für SSL / TLS-Zertifikate kennen.
  5. ol>

    Vor allem aber ist dies kein Sicherheitsrisiko. In jedem Fall.

    Nehmen Sie alle Kommentare hier mit einem großen Stück Salz.

    Ich halte es für wichtig, diese Kommentare anzugeben (auch wenn sie in guter Absicht geschrieben wurden ) sind unbegründet, fehlgeleitet und falsch:

  • "Kompromisse bei anderen Websites können dazu führen, dass Ihr SSL-Verkehr nicht mehr sicher ist" - nein
  • "Hinzufügen einer neuen Bei Domain for Service wird das Zertifikat mit den damit verbundenen Ausfallzeiten erneut ausgestellt. " --nope
  • "Weiterleiten von HTTP-Datenverkehr (Hinweis, kein S) an die realen Server im CDN-Netzwerk." --nope
  • "Ihre Bank verstößt möglicherweise gegen die Datenschutzgesetze in Ihrem Land, indem sie einem Unternehmen aus einem anderen Land unter einer anderen Gesetzgebung erlaubt, die personenbezogenen Daten der Kunden zu verarbeiten." - Mai, aber nein

HTH

Meistens stimmte er der Person aus Incapsula zu, vergaß jedoch eines zu erwähnen.Das Hauptproblem hierbei ist die Leistung.Dieses Shared Cert ist ein UC / SAN, das von GlobalSign an Incapsula ausgestellt wurde.Es enthält eine sehr große Anzahl von SANs, die sich auf die Leistung auswirken werden.Es ist auch ziemlich seltsam zu sehen, dass eine Bank kein EV-Zertifikat verwendet.
Vielen Dank, würde gerne einige Zahlen zu den Auswirkungen auf die Leistung sehen (ohnehin kein Sicherheitsproblem).Wäre es besser, wenn sie einen EV benutzen?sicher.Ist ein Shared-Non-Ev gefährlicher als ein reguläres Non-Ev?Nee.
#6
  0
blfoleyus
2018-09-10 00:05:22 UTC
view on stackexchange narkive permalink

Was die Sicherheit betrifft, nein. Wie von mehreren Personen festgestellt, schützen die CDNs den privaten Schlüssel sicherer als Organisationen.

Das Risiko kann jedoch eher ein Erscheinungsbild sein. Beispielsweise möchte die ABC Bank möglicherweise kein Zertifikat mit XYX Guns und Ammo teilen. Es ist ein Problem mit dem Aussehen.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...