Fire grænser, du skal kontrollere, før du betaler gennem en VPN

Gå de fire grænser igennem i rækkefølge, og de fleste betalingsspørgsmål besvarer sig selv. Den første er det miljø, transaktionen kører i, den anden er den vej, dens trafik tager, den tredje er, om siden er den, du ville nå, og den fjerde er, hvad modtageren lærer om transaktionen uanset vejen. En sikkerhedspakke, der slår en beskyttet browser sammen med en tunnel, indbyder dig til at behandle én knap som én garanti, og det er præcis der, kontrollerne springes over. Hver kontrol har sin egen stopbetingelse, og rækkefølgen betyder noget, fordi en senere ikke kan reparere en tidligere fejl.

Først: hvad begrænser det beskyttede miljø egentlig

Leverandørens tekst til en betalingsmåde nævner som regel begrænsninger: hvilke andre programmer der kan samvirke med sessionen, om udklipsholder og skærmoptagelse er begrænset, om sessionen kører på et særskilt skrivebord. Det, den ikke fastslår, er, at en privilegeret værtskomponent, en driver eller en inputmekanisme uden for sandkassen ikke kan nå sessionen. At være i en sandkasse er en beskrivelse af en grænse, ikke et løfte om enhver angriber.

Læs funktionslisten for den udgave, du faktisk har installeret, fordi sammensatte tilstande ofte varierer mellem forbrugerniveauer og nogle gange mangler på administrerede enheder. Sammenlign den liste med den fejl, du ser, før du antager, at grænsen holdt.

Stop så og spørg, om den fejl, du jager, overhovedet er lokal. Hvis betalingssiden kun vises forkert i den beskyttede tilstand, er miljøet den mistænkte, og tunnelen er irrelevant. Hvis den vises korrekt overalt, men transaktionen stadig fejler, kigger du på den næste grænse, og at svække den beskyttede tilstand hjælper ikke.

Dernæst: hvilken trafik bærer tunnelen

En tunnel beskytter den trafik, den dækker, og dækning er en konfigurationskendsgerning, ikke en produktegenskab. Spørg, om den beskyttede browsers egen trafik er med, om tilstanden omgår tunnelen af hensyn til ydelse eller captive portals, og om en regel for delt tunnel udelukker destinationen. En almindelig browser, der viser udbyderens udgangsadresse, beviser intet om et særskilt browsermiljø startet af en anden proces.

Test dækningen indefra miljøet i stedet for fra skrivebordet. Indlæs en side, der viser din offentlige adresse i den beskyttede session, og sammenlign den med den adresse, du ser udenfor, og gentag så efter at have genoprettet forbindelsen til tunnelen. Hvis de to stemmer overens, mens tunnelen hævder en anden udgang, bruger tilstanden ikke tunnelen, og uoverensstemmelsen er værd at løse, før du indtaster kortoplysninger. Det er også let at overfortolke en ændret udgangsadresse: den fortæller, hvilket netværk forhandleren ser, ikke hvem forhandleren er.

Tredje: bekræft tjenesten i stedet for mærket

Certifikatvalidering er det, der autentificerer destinationen, og det virker stadig efter tunnelens udgang, fordi det er en særskilt mekanisme. Et beskyttet vindue med logo og en Connected-indikator siger intet om den certifikatkæde, som siden du nåede, præsenterer.

Når noget ser forkert ud, så læs certifikatet, før du afviser advarslen. Kommandoen nedenfor beder om den kæde, siden faktisk præsenterer, og beder værktøjet fejle ved en valideringsfejl.

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

Sammenlign emne og udsteder i det output med den adresse, du skrev, og bekræft valideringsresultatet i stedet for tilstedeværelsen af en hængelås. En advarsel inde i en beskyttet browser er stadig en advarsel, og den sædvanlige årsag er uoverensstemmelse i værtsnavn, et kapret DNS-svar eller et aflytningsapparat på vejen. Ingen af dem repareres af tunnelen, og en tilstand, der stiltiende undertrykker advarslen, har fjernet information, du havde brug for.

Fjerde: hvad modtageren alligevel får at vide

Betalingssiden modtager alt, hvad du sender til den: den konto, du logger ind på, leveringsadressen, kortinstrumentet og beløbet. En anden netværksudgang ændrer kildeadressen i forhandlerens logfiler og lader de felter være præcis, som de var. Hvis kontoen allerede er knyttet til dig, har tunnelen ændret en lille del af billedet og intet af den identificerende del. Det er ikke en grund til at springe tunnelen over, kun en grund til at holde op med at forvente, at den klarer dette job.

Bitdefenders Safepay-dokumentation beskriver en beskyttet browser med tilknyttet tunnelintegration, hvilket er et godt eksempel på ét produkt, der dækker to grænser uden at smelte dem sammen. Både miljøet og vejen er nyttige, og ingen af dem garanterer for forhandleren.

For en betaling, du bryder dig om, så start fra organisationens offentliggjorte adresse eller dens officielle applikation, behold de identitetskontroller, siden beder om, og afvis enhver hjælper, som en uventet prompt på betalingssiden tilbyder. Hvis den beskyttede tilstand eller tunnelen forårsager en fejl, så navngiv grænsen først: start af miljøet, adgang til netværket, validering af certifikatet eller autentificering af kontoen. Brug derefter leverandørens understøttede gendannelsesvej for det lag i stedet for at slå beskyttelser fra for at se, om siden indlæses.