Fyra gränser att kontrollera innan du betalar via en VPN

Gå igenom de fyra gränserna i ordning och de flesta betalningsfrågor besvarar sig själva. Den första är miljön transaktionen körs i, den andra är den väg dess trafik tar, den tredje är om webbplatsen verkligen är den du ville nå, och den fjärde är vad mottagaren får veta om transaktionen oavsett väg. Ett säkerhetspaket som slår ihop en skyddad webbläsare med en tunnel inbjuder dig att behandla en knapp som en garanti, och det är just där kontrollerna hoppas över. Varje kontroll har sitt eget stoppvillkor, och ordningen spelar roll eftersom en senare inte kan reparera ett tidigare fel.

Först: vad begränsar den skyddade miljön egentligen

Leverantörens text för ett betalningsläge brukar räkna upp begränsningar: vilka andra program som kan samverka med sessionen, om urklipp och skärminspelning är begränsade, om sessionen körs på ett separat skrivbord. Det den inte fastställer är att en privilegierad värdkomponent, en drivrutin eller en inmatningsmekanism utanför sandlådan inte kan nå sessionen. Att vara i en sandlåda är en beskrivning av en gräns, inte ett löfte om varje angripare.

Läs funktionslistan för den utgåva du faktiskt installerade, eftersom sammanslagna lägen ofta skiljer sig mellan konsumentnivåer och ibland saknas på hanterade enheter. Jämför listan med felet du ser innan du antar att gränsen höll.

Stanna sedan och fråga om felet du jagar ens är lokalt. Om betalningssidan visas fel bara i det skyddade läget är miljön den misstänkta och tunneln irrelevant. Om den visas korrekt överallt men transaktionen ändå misslyckas tittar du på nästa gräns, och att försvaga det skyddade läget hjälper inte.

Sedan: vilken trafik bär tunneln

En tunnel skyddar den trafik den täcker, och täckningen är ett konfigurationsfaktum, inte en produktegenskap. Fråga om den skyddade webbläsarens egen trafik ingår, om läget kringgår tunneln av prestanda- eller captive portal-skäl, och om en regel för delad tunnel utesluter målet. En vanlig webbläsare som visar leverantörens utgångsadress bevisar ingenting om en separat webbläsarmiljö som startats av en annan process.

Testa täckningen inifrån miljön i stället för från skrivbordet. Läs in en sida som visar din publika adress i den skyddade sessionen och jämför den med adressen du ser utanför, och upprepa sedan efter att ha återanslutit tunneln. Om de två stämmer medan tunneln hävdar en annan utgång använder läget inte tunneln, och avvikelsen är värd att lösa innan du anger kortuppgifter. Det är också lätt att övertolka en ändrad utgångsadress: den säger vilket nätverk handlaren ser, inte vem handlaren är.

Tredje: bekräfta tjänsten i stället för märket

Certifikatvalidering är det som autentiserar målet, och det fortsätter att fungera efter tunnelutgången eftersom det är en separat mekanism. Ett skyddat fönster med varumärke och en Connected-indikator säger ingenting om den certifikatkedja som webbplatsen du nådde presenterar.

När något verkar fel, läs certifikatet innan du avvisar varningen. Kommandot nedan begär den kedja webbplatsen faktiskt presenterar och säger åt verktyget att misslyckas vid ett verifieringsfel.

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

Jämför ämnet och utgivaren i den utskriften med adressen du skrev, och bekräfta verifieringsresultatet i stället för förekomsten av ett hänglås. En varning inne i en skyddad webbläsare är fortfarande en varning, och den vanliga orsaken är ett namnfel på värden, ett kapat DNS-svar eller en avlyssningsenhet på vägen. Inget av det repareras av tunneln, och ett läge som tyst undertrycker varningen har tagit bort information du behövde.

Fjärde: vad mottagaren ändå får veta

Betalningssidan tar emot allt du skickar till den: kontot du loggar in på, leveransadressen, kortinstrumentet och beloppet. En annan nätverksutgång ändrar källadressen i handlarens loggar och lämnar fälten exakt som de var. Om kontot redan är knutet till dig har tunneln ändrat en liten del av bilden och ingenting av den identifierande delen. Det är inte ett skäl att hoppa över tunneln, bara ett skäl att sluta förvänta sig att den gör det här jobbet.

Bitdefenders Safepay-dokumentation beskriver en skyddad webbläsare med tillhörande tunnelintegration, vilket är ett bra exempel på en produkt som täcker två gränser utan att smälta samman dem. Både miljön och vägen är användbara, och ingen av dem garanterar för handlaren.

För en betalning du bryr dig om, börja från organisationens publicerade adress eller dess officiella applikation, behåll de identitetskontroller webbplatsen begär och avvisa varje hjälpare som en oväntad uppmaning på betalningssidan erbjuder. Om det skyddade läget eller tunneln orsakar ett fel, namnge först gränsen: starta miljön, nå nätverket, validera certifikatet eller autentisera kontot. Använd sedan leverantörens stödda återställningsväg för det lagret i stället för att stänga av skydd för att se om sidan laddas.