Vier Grenzen, die vor einer Zahlung über ein VPN zu prüfen sind

Arbeiten Sie die vier Grenzen der Reihe nach ab, und die meisten Fragen zur Zahlung beantworten sich selbst. Die erste ist die Umgebung, in der die Transaktion läuft, die zweite der Weg, den ihr Datenverkehr nimmt, die dritte, ob die Website wirklich die ist, die Sie erreichen wollten, und die vierte, was der Empfänger unabhängig vom Weg über die Transaktion erfährt. Eine Sicherheitssuite, die einen geschützten Browser mit einem Tunnel bündelt, lädt dazu ein, eine Schaltfläche als eine Garantie zu behandeln, und genau dort werden die Prüfungen übersprungen. Jede Prüfung hat ihre eigene Abbruchbedingung, und die Reihenfolge zählt, weil eine spätere einen früheren Fehler nicht reparieren kann.

Erstens: Was schränkt die geschützte Umgebung wirklich ein

Herstellertexte zu einem Zahlungsmodus nennen meist Einschränkungen: welche anderen Anwendungen mit der Sitzung interagieren können, ob Zwischenablage und Bildschirmaufnahme begrenzt sind, ob die Sitzung auf einem getrennten Desktop läuft. Was sie nicht belegen, ist, dass eine privilegierte Hostkomponente, ein Treiber oder ein Eingabemechanismus außerhalb der Sandbox die Sitzung nicht erreichen kann. In einer Sandbox zu laufen beschreibt eine Grenze, es ist kein Versprechen gegenüber jedem Angreifer.

Lesen Sie die Funktionsliste für die Edition, die Sie tatsächlich installiert haben, denn gebündelte Modi unterscheiden sich oft zwischen Verbraucherstufen und fehlen manchmal auf verwalteten Geräten. Vergleichen Sie diese Liste mit dem Fehler, den Sie sehen, bevor Sie annehmen, die Grenze habe gehalten.

Dann halten Sie inne und fragen sich, ob der Fehler, dem Sie nachgehen, überhaupt lokal ist. Wird die Zahlungsseite nur im geschützten Modus falsch dargestellt, ist die Umgebung verdächtig und der Tunnel irrelevant. Wird sie überall korrekt dargestellt, scheitert die Transaktion aber weiterhin, betrachten Sie die nächste Grenze, und ein Abschwächen des geschützten Modus hilft nicht.

Zweitens: Welchen Datenverkehr trägt der Tunnel

Ein Tunnel schützt den Datenverkehr, den er abdeckt, und Abdeckung ist eine Konfigurationstatsache, keine Produkteigenschaft. Fragen Sie, ob der eigene Datenverkehr des geschützten Browsers enthalten ist, ob der Modus den Tunnel aus Leistungs- oder Captive-Portal-Gründen umgeht und ob eine Split-Tunnel-Regel das Ziel ausschließt. Ein gewöhnlicher Browser, der die Ausgangsadresse des Anbieters zeigt, beweist nichts über eine separate Browsing-Umgebung, die von einem anderen Prozess gestartet wurde.

Prüfen Sie die Abdeckung von innerhalb der Umgebung statt vom Desktop aus. Laden Sie eine Seite, die Ihre öffentliche Adresse in der geschützten Sitzung anzeigt, vergleichen Sie sie mit der Adresse, die Sie außerhalb sehen, und wiederholen Sie das nach erneutem Verbinden des Tunnels. Stimmen beide überein, während der Tunnel einen anderen Ausgang behauptet, nutzt der Modus den Tunnel nicht, und diese Abweichung sollte geklärt werden, bevor Sie Kartendaten eingeben. Auch ein Wechsel der Ausgangsadresse lässt sich leicht überinterpretieren: Er sagt, welches Netz der Händler sieht, nicht wer der Händler ist.

Drittens: Prüfen Sie den Dienst statt das Abzeichen

Die Zertifikatsprüfung ist das, was das Ziel authentifiziert, und sie funktioniert nach dem Tunnelausgang weiter, weil sie ein eigener Mechanismus ist. Ein gebrandetes geschütztes Fenster und eine Connected-Anzeige sagen nichts über die Zertifikatskette aus, die die erreichte Website vorlegt.

Wenn etwas falsch aussieht, lesen Sie das Zertifikat, bevor Sie die Warnung verwerfen. Der folgende Befehl fragt die Kette ab, die die Website tatsächlich vorlegt, und weist das Werkzeug an, bei einem Prüffehler zu scheitern.

openssl s_client -connect shop.example:443 -servername shop.example -verify_return_error

Vergleichen Sie Betreff und Aussteller in dieser Ausgabe mit der eingegebenen Adresse und bestätigen Sie das Prüfergebnis statt das Vorhandensein eines Vorhängeschlosses. Eine Warnung in einem geschützten Browser bleibt eine Warnung, und die übliche Ursache ist eine Namensabweichung beim Host, eine gekaperte DNS-Antwort oder ein Abfanggerät auf dem Weg. Nichts davon repariert der Tunnel, und ein Modus, der die Warnung stillschweigend unterdrückt, hat Informationen entfernt, die Sie brauchten.

Viertens: Was der Empfänger trotzdem erfährt

Die Zahlungsseite erhält alles, was Sie ihr übermitteln: das Konto, in das Sie sich einloggen, die Lieferadresse, das Karteninstrument und den Betrag. Ein anderer Netzwerkausgang ändert die Quelladresse in den Protokollen des Händlers und lässt diese Felder genau so, wie sie waren. Ist das Konto bereits mit Ihnen verknüpft, hat der Tunnel einen kleinen Teil des Bildes verändert und nichts vom identifizierenden Teil. Das ist kein Grund, den Tunnel auszulassen, nur ein Grund, nicht mehr zu erwarten, dass er diese Aufgabe erledigt.

Die Dokumentation von Bitdefender zu Safepay beschreibt einen geschützten Browser mit zugehöriger Tunnelintegration, was ein gutes Beispiel für ein Produkt ist, das zwei Grenzen abdeckt, ohne sie zu verschmelzen. Umgebung und Weg sind beide nützlich, und keines von beiden bürgt für den Händler.

Beginnen Sie bei einer Zahlung, die Ihnen wichtig ist, mit der veröffentlichten Adresse der Organisation oder ihrer offiziellen Anwendung, behalten Sie die Identitätsprüfungen bei, die die Website verlangt, und lehnen Sie jede Hilfe ab, die eine unerwartete Aufforderung auf der Zahlungsseite anbietet. Verursacht der geschützte Modus oder der Tunnel einen Fehler, benennen Sie zuerst die Grenze: Starten der Umgebung, Erreichen des Netzwerks, Prüfen des Zertifikats oder Authentifizieren des Kontos. Nutzen Sie dann den unterstützten Wiederherstellungsweg des Anbieters für diese Schicht, statt Schutzfunktionen abzuschalten, um zu sehen, ob die Seite lädt.