it-swarm.com.de

Was sind die Unterschiede zwischen dem Überprüfen eines selbstsignierten Zertifikats und dem Ignorieren?

Ich mache eine Integration mit einem System, das ein selbstsigniertes Zertifikat hat. Bei der ersten Entwicklung ignorieren wir die Zertifikatprüfung, um einige Fehler zu umgehen:

Ausnahme im Thread "main" javax.net.ssl.SSLHandshakeException: Sun.security.validator.ValidatorException: PKIX-Pfaderstellung fehlgeschlagen: Sun.security.provider.certpath.SunCertPathBuilderException: Es konnte kein gültiger Zertifizierungspfad zum angeforderten Ziel gefunden werden

weil wir zuerst verstehen müssen, wie man das Zertifikat mit Java keytool in einer Docker-Umgebung hinzufügt.

Meine Frage ist jedoch: Was ist in diesem Fall der Vorteil, ein selbstsigniertes Zertifikat als "vertrauenswürdiges Zertifikat" zu importieren, wenn ich es einfach ignorieren könnte?

11
Dherik

Wenn es sich um einen offiziellen Dienst handelt, den Sie in den Anbieter integrieren, sollte wirklich aus Sicherheitsgründen ein gültiges, öffentlich signiertes Zertifikat installiert sein.

Angenommen, Sie müssen mit Ihrem Anbieter ein selbstsigniertes Zertifikat verwenden, besteht der große Unterschied zwischen dem Ignorieren des Zertifikats und dem Hinzufügen als vertrauenswürdig im folgenden Szenario. Dies ist eine DNS-Vergiftung als Beispiel für einen Mann im mittleren Angriff.

Nehmen Sie das folgende Beispiel:

  • api.example.com hat ein selbstsigniertes Zertifikat mit Fingerabdruck XXX, das die IP abhört 5.5.5.5.
  • Wenn Sie es Ihrem Trust Store hinzufügen, erwartet Ihr System, dass der Fingerabdruck beim Herstellen einer Verbindung XXX beträgt
  • Wenn jemand Ihr DNS vergiften konnte - machen Sie api.example.com beschließe zu 6.6.6.6 - der Fingerabdruck wäre JJJ.
  • Durch Hinzufügen des Zertifikats zu Ihrem Geschäft würde Ihr Produkt die Verbindung zur schädlichen Site verweigern.
  • Wenn Sie die Prüfung vollständig deaktivieren, stellt Ihr Produkt gerne eine Verbindung zum böswilligen api.example.com beim 6.6.6.6.
25
Tim Brigham

Durch den Import eines bekannten guten selbstsignierten Zertifikats, bei dem der private Schlüssel eindeutig und nicht gefährdet ist, ist die Verbindung genauso sicher wie ein vollständiges globales CA PKI-signiertes Zertifikat. Diese werden schließlich auch irgendwann einfach gespeichert und vertrauenswürdig.

Der Grund, ein von der PKI-Zertifizierungsstelle signiertes Zertifikat zu erhalten, liegt eher in der Praktikabilität als in der Sicherheit. Wenn Sie auf vielen Clients einem selbstsignierten Zertifikat vertrauen müssen, kann dies eine Menge Arbeit bedeuten. Und das Drehen der Tasten erhöht diese Arbeit fast exponentiell.

Wenn Sie den Server und den Client wie während der Entwicklung steuern und nicht über die erforderlichen Fähigkeiten oder Ressourcen verfügen, um eine private Zertifizierungsstelle einzurichten, ist das Hinzufügen eines bestimmten selbstsignierten Zertifikats zu einem Trust Store nicht so schlecht. Das Akzeptieren von any Zertifikaten ist schlecht, tun Sie das niemals.

16
John Keates

Wenn Sie die Zertifikatsprüfung ignorieren, kann jeder, der die Man-in-the-Middle-Position (mit der Möglichkeit, den Datenverkehr zu ändern) zwischen Ihnen und dem anderen System erreichen kann, den Nur-Text-Datenverkehr lesen/ändern. Ein Angreifer unterbricht einfach den TLS/SSL-Tunnel, indem er seinen eigenen TLS-Server mit seinem selbstsignierten Zertifikat startet, Ihren Datenverkehr dorthin leitet, entschlüsselt und an den realen Server weiterleitet. Es gibt viele Tools, die diesen Angriff ziemlich einfach machen, zum Beispiel mitmproxy für HTTPS oder stunnel im Allgemeinen für TLS/SSL.

Ein Angriff kann auf viele verschiedene Arten in die Position des Mannes in der Mitte gelangen. Es ist daher schwer auszuschließen, dass ein Angreifer diese Position nicht erreichen kann, selbst wenn Sie ein Netzwerksicherheitsexperte sind.

Wenn es keine Möglichkeit gibt, das selbstsignierte Zertifikat durch ein öffentlich signiertes Zertifikat zu ersetzen, können Sie dem selbstsignierten Zertifikat manuell vertrauen, indem Sie es mit keytool zu einem Java Keystore) hinzufügen und vertrauen Sie diesem Speicher. Dies wird manchmal als Zertifikat oder Pinning von öffentlichen Schlüsseln bezeichnet

3
sven.to

Zertifikate sind die Art und Weise, wie der Unterzeichner für den Unterzeichner bürgen kann. Wenn Sie dem Unterzeichner vertrauen, können Sie dem Zertifikat und dem signierten öffentlichen Schlüssel vertrauen. Wenn Sie dem Unterzeichner vertrauen, können Sie das Zertifikat ignorieren.

In realeren Begriffen:

Beispiel 1: Cindy Certificateauthority ist sehr bekannt. Jeder kennt Cindy. Cindy hat einen wirklich guten Ruf, um zu überprüfen, wer Menschen wirklich sind, bevor sie sie anderen Menschen vorstellt. Jemand behauptet, Pablo Pubkey zu sein - ein bekannter und vertrauenswürdiger Verkäufer - möchte Ihnen etwas verkaufen. Cindy stellt Sie dieser Person vor und sagt, dass sie Pablo ist. Du vertraust Cindy, also glaubst du, dass die Person Pablo ist, und beschließt, Pablo deine Kreditkartennummer zu geben und Sachen zu kaufen.

Beispiel 2: Sie sind mit Freddy Friend aufgewachsen, seit Sie ein Kind waren. Sie wissen, wer Freddy ist - Sie haben ihn im Kindergarten getroffen und gesehen, wie er neben Ihnen erwachsen wurde. Freddy ist auch ein Verkäufer. Wenn du mit Freddy sprechen willst, suchst du einfach Freddy - du brauchst niemanden, der dich ihm vorstellt.

Im ersten Beispiel haben Sie sich auf eine Zertifizierungsstelle verlassen, der Sie vertrauen, um Ihnen mitzuteilen, wem ein bestimmter öffentlicher Schlüssel gehört. Im zweiten Beispiel hatten Sie direktes Vertrauen in den öffentlichen Schlüssel und brauchten keinen Dritten, der Ihnen mitteilte, wem er gehört. Beispielsweise kann Ihre Software ihren Benutzern öffentliche Schlüssel ausgeben und diese öffentlichen Schlüssel in der Datenbank Ihrer Software zuordnen. Dieses zweite Beispiel ist genau das gleiche, wenn Sie ein selbstsigniertes Zertifikat und ein nicht signiertes Zertifikat haben.

1
atk