it-swarm.com.de

Warum sollte jemand "doppelt verschlüsseln"?

Wenn ich eine Website oder eine mobile App habe, die über eine gesicherte SSL/TLS-Verbindung (dh HTTPS) mit dem Server spricht und die zwischen Benutzer und Server zusätzlich zu der bereits sicheren Verbindung gesendeten und empfangenen Nachrichten verschlüsselt, werde ich dies tun unnötige Bewegungen machen? Oder ist Doppelverschlüsselung eine gängige Methode? Wenn ja warum?

91
Lighty

Es ist nicht ungewöhnlich, aber möglicherweise nicht erforderlich. Viele Entwickler scheinen zu vergessen, dass der HTTPS-Verkehr bereits verschlüsselt ist. Sehen Sie sich nur die Anzahl der Fragen zur Implementierung der clientseitigen Verschlüsselung auf dieser Website an. Lenovo SSL MitM Chaos .

Die meisten Menschen waren davon jedoch nicht betroffen, und es gibt derzeit keine besonders praktikablen Angriffe gegen TLSv1.2, sodass es nicht wirklich viel bringt.

Andererseits gibt es in einigen Fällen legitime Gründe, Daten vor der Übertragung zu verschlüsseln. Wenn Sie beispielsweise eine Speicheranwendung entwickeln, möchten Sie möglicherweise mithilfe einer App auf der Clientseite mit einem Schlüssel verschlüsseln, der nur dem Benutzer bekannt ist. Dies würde bedeuten, dass der Server die Daten überhaupt nicht entschlüsseln kann. aber es könnte es immer noch speichern. Das Senden über HTTPS würde bedeuten, dass ein Angreifer auch nicht in der Lage sein sollte, die vom Client verschlüsselten Daten abzurufen, aber selbst wenn dies der Fall wäre, wäre dies nicht wichtig. Dieses Muster wird häufig von Cloud-basierten Passwort-Managern verwendet.

Im Wesentlichen hängt es davon ab, gegen was Sie sich verteidigen - wenn Sie SSL/TLS nicht vertrauen, können Sie dem von Ihnen gesendeten Verschlüsselungscode (im Fall der Webanwendung) wahrscheinlich auch nicht vertrauen!

117
Matthew

HTTPS bietet nur Verschlüsselung, während die Nachricht über das Netzwerk/Internet übertragen wird.

Wenn die Nachricht irgendwann zwischen dem Client und dem Server, der sie schließlich verarbeitet, von einem Vermittler (z. B. einer Nachrichtenwarteschlange) gespeichert oder verarbeitet wird, bleibt sie nicht verschlüsselt, solange sie sich im Vermittler befindet.

Wenn das TLS/SSL an den Dienstperimetern (z. B. auf einem Load Balancer) beendet wird, wird es möglicherweise nicht im internen Netzwerk verschlüsselt. Dies kann ein Problem sein, wenn eine hohe Sicherheit erforderlich ist, beispielsweise in einigen regulierten Umgebungen.

In beiden Fällen stellt die Verschlüsselung auf Nachrichtenebene sicher, dass die Daten an allen Punkten zwischen dem Client und dem endgültigen Empfänger verschlüsselt werden.

Wie @honze sagte, wird dies als Tiefenverteidigung bezeichnet und soll sicherstellen, dass selbst dann, wenn ein System teilweise kompromittiert ist (z. B. ein Man-in-the-Middle-Angriff durchgeführt wird, um das SSL/TLS zu kompromittieren oder a auszunutzen) Sicherheitslücke in der Nachrichtenwarteschlange, um auf die Daten in Ruhe zuzugreifen) Der Angreifer kann nicht auf die geschützten Daten zugreifen.

98
Mike Goodwin

Ich möchte meine Erfahrungen mit der Titelfrage teilen. Es hängt nicht wirklich mit der vollständigen Frage selbst zusammen, aber dies beantwortet die Frage "Warum sollte jemand doppelt verschlüsseln?"

In der Vergangenheit habe ich für eine Organisation gearbeitet, die die Kommunikation zwischen Leistungserbringern (Ärzten, Krankenhäusern usw.) und Versicherungsorganisationen (Gegenseitigkeiten) übernimmt. Wir haben uns wie ein Router verhalten.

Das Schema war ungefähr das folgende:

care provider 1 \                   / insuring organization 1
care provider 2 ---- router (us) ---- insuring organization 2
care provider 3 /                   \ insuring organization 3

Wir hatten folgenden Schutz:

  1. End-to-End-Verschlüsselung : Der Leistungserbringer 1 muss Patienteninformationen an die Versicherungsorganisation 1 senden. Diese Informationen sind datenschutzrelevant und müssen daher verschlüsselt werden. Auf unserer Ebene haben wir kein Recht zu wissen, welche Daten an die Versicherungsorganisation gesendet werden.
  2. Care-Provider - Router-Verschlüsselung : Der Care-Provider sendet Informationen als Metadaten, damit wir damit umgehen können. Diese Informationen müssen verschlüsselt werden. Der Vertrag sah vor, dass die Nachrichten auch innerhalb unseres Netzwerks noch verschlüsselt werden mussten, damit nur einer unserer Server jemals die Metadaten der gesendeten Informationen kennt. Da wir mehrere Pipes haben (Load Balancer, Firewall usw.), ist auch auf dieser Ebene eine Verschlüsselung erforderlich.
  3. HTTPS zur Vermeidung von MITM-Angriffen : Unsere Daten mussten nicht nur geschützt werden, sondern auch die HTTP-Metadaten, also HTTPS.

Ich hoffe, dies gibt Aufschluss darüber, warum mehrere Verschlüsselungsebenen erforderlich sein können.

29

Du hast recht. Dies ist ein mehrschichtiges Sicherheitskonzept, das als Tiefenverteidigung bezeichnet wird.

Die verschlüsselten Nachrichten adressieren wahrscheinlich die End-to-End-Verschlüsselung, und SSL/TLS adressiert die Verschlüsselung der Metadaten. Dies ist ein nützliches Muster.

15
honze

HTTPS wird während der Übertragung verschlüsselt und an den Enden entschlüsselt. Die offensichtliche Situation, in der Sie möglicherweise doppelt verschlüsseln möchten, ist die, in der Sie nicht möchten, dass eines (oder möglicherweise beide!) Der Enden das sehen Klartext.

Einige Situationen, die mir auf den ersten Blick einfallen:

  • verschlüsselte E-Mails über Webmail-Anbieter. Wenn ich eine GPG-verschlüsselte Nachricht über Google Mail sende, auf die ich über eine HTTPS-Verbindung zugreife, wird sie zweimal verschlüsselt. Weil ich nicht möchte, dass Google Mail den Inhalt liest.

  • verschlüsselte Sicherungsdienste. Ich möchte HTTPS verwenden, um zu verhindern, dass meine Anmeldeinformationen gestohlen werden, aber ich möchte nicht, dass der Sicherungsdienst "in" den Sicherungen angezeigt wird.

  • zahlungsgateways. Sie können sich eine vorstellen, bei der eine verschlüsselte Nachricht zwischen einem sicheren Zahlungshardware-Token und einer Bank über das unsichere Gerät eines Benutzers und die Website eines Händlers gesendet wird. Der Link in der Mitte sollte HTTPS sein, aber das reicht nicht aus: Er muss auf dem unsicheren PC und auf der Website eines weniger sicheren Händlers verschlüsselt werden.

Beachten Sie, dass S/MIME "Triple Wrap" (sign/encrypt/sign) vorsieht: https://tools.ietf.org/html/rfc2634 Wenn Sie also in Betracht ziehen, auch zu signieren und zu verschlüsseln Weitere Möglichkeiten können sinnvoll sein.

9
pjc50

Ich wollte einen zusätzlichen Grund nennen: Standardisierung.

Ich habe eine Anwendung, bei der aus Sicherheitsgründen alle ein- und ausgehenden Daten verschlüsselt werden müssen. Da es bereits einmal verschlüsselt ist, dürfen die Daten sowohl über http (Legacy) - als auch über https (Current) -Verbindungen fließen. Es ist viel sinnvoller, zweimal zu verschlüsseln, als eine Version der Anwendung zu erstellen, die unverschlüsselt über https und verschlüsselt über http ausgeführt wird.

8
user1361991

Es handelt sich um bewährte Methoden beim Umgang mit hochsensiblen Informationen wie finanziellen, medizinischen, militärischen oder psychologischen Daten. Die Grundidee mehrerer Verschlüsselungen besteht darin, zu verhindern, dass nicht autorisierte Benutzer die Daten abrufen. Angenommen, die anfänglich möglichen Kombinationen für die Verschlüsselungsmethode betrugen 1 Milliarde. Durch Anwenden einer anderen Verschlüsselungsmethode könnten wir die Möglichkeiten mit 1b ^ 3 multiplizieren. Es würde erfordern, dass ein nicht autorisierter Benutzer länger braucht, um die Daten zu entschlüsseln. Die Verschlüsselung ist zwar immer noch nicht perfekt, aber besser.

In einer der Organisationen, in denen ich gearbeitet habe, haben wir mehrere Verschlüsselungen verwendet. Dies ist eine Vereinfachung des vorherigen Ablaufs:

  • Überprüfen Sie sowohl Client- als auch Servergeräte und -komponenten auf Freigabe über Software
  • Verschlüsseln Sie die Daten im Speicher
  • Daten komprimieren
  • Verschlüsseln Sie Daten mit proprietärer Software
  • Beginnen Sie die Verbindung mit dem Server
  • Überprüfen Sie sowohl Client- als auch Servergeräte und -komponenten auf Freigabe über Verbindung
  • Getriebe komprimieren
  • Daten über Verschlüsselungsverbindung senden; Wenn die Verbindung getrennt wird, starten Sie den gesamten Prozess neu.
  • Überprüfen Sie nach erfolgreichem Abschluss der Datei die Daten auf Konsistenz

Wenn Sie nicht mit einer netzwerkreichen Umgebung mit vertraulichen Daten zu tun haben, ist dies ein Overkill.

Die Strategie hinter dieser Methode stellt sicher, dass die Geräte, Komponenten (MAC) und IP authentifiziert wurden. Das Verschlüsseln von Daten ist ein Standardverfahren, ebenso wie das Senden über HTTPS. Einige Organisationen gehen über die grundlegende Sicherheit hinaus und benötigen auch Darknet-ähnliche Netzwerke, die Freenet, I2P, IPsec/VPN oder Tor verwenden, um eine Verbindung herzustellen. Unabhängig von der Verschlüsselung reduziert die Datenkomprimierung die erforderlichen Speicher- und Netzwerkressourcen. Ihre Leistung wird jedoch auf RAM oder Verarbeitung) verschoben. Der Grund, warum wir die Verbindung nach einer Trennung neu gestartet haben, ist, dass wir einen Weg gefunden haben, den Datenstrom über Man-in-the-Middle zu entführen .

Letztendlich gibt es keine perfekte Möglichkeit, Daten für immer zu verschlüsseln. Konzentrieren Sie sich jedoch auf die Verschlüsselung, bis die Daten oder Informationen irrelevant werden oder Sie eine überlegene Methode zum Verschlüsseln von Daten finden.

3
LJones

Es gibt eine Reihe von Gründen für das Senden verschlüsselter Daten über eine verschlüsselte Verbindung:

  • selbst wenn die Verschlüsselung der Verbindung unterbrochen ist (z. B. MitM, möglich, aber mit HTTPS schwierig, und zum Abfangen aller übertragenen Daten führt), werden die Daten immer noch verschlüsselt
  • der HTTPS-Server ist möglicherweise nicht vertrauenswürdig und für die Weiterleitung der Daten an einen anderen Server verantwortlich
  • in ähnlicher Weise kann der HTTPS-Server die Daten über eine unverschlüsselte Verbindung an einen anderen Server weiterleiten, und wenn der Client die Daten vor der Übertragung verschlüsselt, wird die Belastung des HTTPS-Servers verringert, der andernfalls die Daten aller Clients verschlüsseln müsste, anstatt sie weitergeben zu können gerade durch
3
Micheal Johnson

API-Verschleierung

Selbst wenn die gesamte Kommunikation über HTTPS verschlüsselt ist, kann der Client seinen Datenverkehr vor der Verschlüsselung mit verschiedenen Debugging-Tools anzeigen. Insbesondere, wenn Sie eine Browserumgebung oder eine App mit https verwenden, die von einem zugrunde liegenden System bereitgestellt wird.

In diesem Fall könnten Sie Ihre Daten mit einem statischen Schlüssel verschlüsseln, sodass der Client den Datenverkehr nicht einfach lesen und bearbeiten kann. Dies ist natürlich nur eine Verschleierung, da der Schlüssel irgendwo auf dem Client-Computer gespeichert werden muss (zumindest im RAM), aber mit Software-Quellcode ist es immer nur eine Verschleierung. Der Benutzer müsste einige erhebliche Anstrengungen unternehmen, um Ihren Schlüssel wiederherzustellen und Ihren Datenverkehr zu entschlüsseln, um seine Anforderungen zu lesen und zu manipulieren.

Beispiele könnten ein webbasiertes Spiel sein, bei dem die Spieler einen Highscore erzielen.

2
Falco

Wenn ich es richtig verstanden habe, funktioniert das Tor-Netzwerk folgendermaßen:

Alice schreibt einen Brief an Dave und verschlüsselt ihn dreimal: zuerst mit Daves Schlüssel, dann mit Daves Adresse, verschlüsselt das Paket mit Craigs Schlüssel, fügt Craigs Adresse hinzu und verschlüsselt das Paket mit Bobs Schlüssel.

Dann schickt sie den Brief an Bob, der ihn entschlüsselt, die Adresse von Craig findet und an ihn weiterleitet.

Craig entschlüsselt es, findet Daves Adresse und leitet sie an ihn weiter. Dave entschlüsselt es und stellt fest, dass der Brief für ihn ist

In einer perfekten Welt konnte niemand außer Alice und Dave jetzt sagen, dass Dave tatsächlich der Empfänger dieses Briefes ist, denn es KÖNNTE sein, dass er Emilys Adresse im Umschlag gefunden und weitergeleitet hatte.

Eine zweite Anwendung wäre, dass Sie eine Nachricht sowohl mit Ihrem privaten Schlüssel als auch mit dem öffentlichen Schlüssel des Empfängers verschlüsseln. Der Empfänger entschlüsselt die Nachricht mit Ihrem öffentlichen Schlüssel und seinem privaten Schlüssel und kann so die Information erhalten, dass die Nachricht von Ihnen und für ihn stammt. In der Regel wird jedoch ein HMAC verwendet, um sicherzustellen, dass die Nachricht tatsächlich von einem bestimmten Absender stammt und nicht manipuliert wurde.

1
Alexander

Der Hauptgrund für die mehrstufige Verschlüsselung ist die Trennung von Bedenken.

Oft kann ein Datensatz von mehreren Servern verarbeitet werden, die möglicherweise von mehreren Organisationen gesteuert werden, denen nicht alle die gesamten Daten vollständig vertrauen. In den meisten Fällen müssen die meisten dieser Zwischenserver nur auf Teile der Daten reagieren. Wenn sie also einige Teile der Daten nicht sehen müssen, kann dieser Teil verschlüsselt werden. Sie würden dem Zwischenzugriff auf die Daten gewähren, die in einem Schlüssel verschlüsselt angezeigt werden sollen, und auf verschlüsselte Blobs, die sie zur weiteren Verarbeitung an andere Server weitergeben können.

Das einfachste Beispiel ist E-Mail mit GPG- und TLS-Verschlüsselung. Die Hauptaufgabe eines Mail-Transfer-Agenten (E-Mail-Relays) besteht darin, E-Mails von einem Hop zum nächsten zu übertragen. Sie müssen die Mail-Routing-Informationen sehen, um ihre Arbeit zu erledigen, aber sie sollten die Nachrichten selbst nicht sehen müssen. Auf diese Weise würden Sie die E-Mail-Verbindung doppelt mit einem Schlüssel verschlüsseln, den der Mail-Transfer-Agent verstehen kann, und die Nachricht mit einem anderen Schlüssel, den nur der Empfänger versteht.

Ein weiteres Beispiel ist der Kalender-/Benachrichtigungsplanungsdienst. Sie fügen Ereignisse in Ihren Kalender ein, um von Ihrer Kalenderanwendung benachrichtigt zu werden, dass zu einem bestimmten Zeitpunkt etwas passiert. Der Kalender musste nicht wissen, was das Ereignis ist, wer an den Ereignissen beteiligt ist oder wo sich das Ereignis befindet.

Ein sekundärer Grund für die Mehrfachverschlüsselung ist die Versicherung für den Fall, dass eine der Verschlüsselungsschichten unterbrochen ist. IMO, dies ist ein viel schwächerer Grund, da Sie berücksichtigen müssen, dass jede unnötige zusätzliche Schicht die Komplexität der Implementierung erhöht und die Komplexität der Feind der Sicherheit ist.

1
Lie Ryan

Ich sehe das hier nicht erwähnt, aber ich denke, es ist etwas wichtiger als ein Kommentar. Sie könnten das für perfekte Vorwärtsgeheimnis tun . Ein Angreifer kennt möglicherweise nicht den Schlüssel für Ihre HTTPS-Verbindung, zeichnet jedoch möglicherweise jedes einzelne Byte auf und speichert es jahrelang. Dann hacken sie Sie möglicherweise auf der ganzen Linie, entdecken eine Sicherheitsanfälligkeit oder zwingen Sie, den privaten Schlüssel Ihres Servers später preiszugeben. Gehen Sie dann in den Verlauf zurück und entschlüsseln Sie Ihre Nachrichten. Durch einen temporären kurzlebigen Schlüssel , der Nachrichten unter der HTTPS-Verbindung verschlüsselt, kann der Angreifer die Nachrichten immer noch nicht lesen oder zumindest erheblich verzögern.

1
Chloe

Nicht gerade ein HTTPS-Problem, aber ein weiterer gültiger Anwendungsfall der doppelten Verschlüsselung wird häufig in Tor verwendet, falls "Ich glaube dem Zusteller nicht und möchte anonym bleiben, indem ich mehr Schritte verwende".

Jeder "Lieferbote" entschlüsselt nur den Umschlag, um den anderen Lieferboten herauszufinden. Die Kommunikation ist in diesem Fall im SOCKS-Proxy gekapselt und verschlüsselt.

0
Jakuje

Derzeit gibt es wahrscheinlich Fehler in Algorithmen und Implementierungen, die noch entdeckt werden müssen. Im Idealfall würden diese Mängel nicht existieren, aber sie existieren.

Wenn Sie mit zwei verschiedenen Algorithmen verschlüsseln und nur einer fehlerhaft ist, sind Sie immer noch in Ordnung und Ihre Daten sind sicher. Wenn die erste Ebene unterbrochen ist, kann ein Angreifer nur Chiffretext abrufen. Wenn die zweite Ebene unterbrochen ist, kann ein Angreifer die erste Ebene nicht passieren.

Eine doppelte Verschlüsselung (oder eine dreifache oder vierfache oder ..) kann ein guter Weg sein, um zu vermeiden, dass alle Eier in einen Korb gelegt werden.

0
Shelvacu

Um Probleme mit der PCI-Konformität zu vermeiden, wenn der Entwickler das Zahlungsgateway verwenden möchte und die Konformität dem Dritten auferlegt.

Die Felder im Formularbeitrag können clientseitig verschlüsselt werden, sodass der Entwickler keine unverschlüsselten Kartendetails über seine Systeme erhält (also einen Schritt weiter, als sie nicht zu speichern).

Insbesondere ist dies zusätzlich zu HTTPS . Somit sieht die Website nicht einmal die unverschlüsselten Daten, sondern nur den Benutzer und das Zahlungsgateway.

Beispiel mit dem Brain Tree-Zahlungsgateway: https://www.braintreepayments.com/blog/client-side-encryption/

0
Alex KeySmith