Fire grenser du bør kontrollere før du betaler gjennom en VPN

Gå gjennom de fire grensene i rekkefølge, og de fleste betalingsspørsmål besvarer seg selv. Den første er miljøet transaksjonen kjører i, den andre er veien trafikken tar, den tredje er om nettstedet faktisk er det du ville nå, og den fjerde er hva mottakeren lærer om transaksjonen uansett vei. En sikkerhetspakke som slår sammen en beskyttet nettleser og en tunnel, inviterer deg til å behandle én knapp som én garanti, og det er nettopp der kontrollene hoppes over. Hver kontroll har sin egen stoppbetingelse, og rekkefølgen betyr noe fordi en senere ikke kan reparere en tidligere feil.

Først: hva begrenser egentlig det beskyttede miljøet

Leverandørens tekst for en betalingsmodus nevner vanligvis begrensninger: hvilke andre programmer som kan samhandle med økten, om utklippstavlen og skjermopptak er begrenset, om økten kjører på et eget skrivebord. Det den ikke fastslår, er at en privilegert vertskomponent, en driver eller en inndatamekanisme utenfor sandkassen ikke kan nå økten. Å være i en sandkasse er en beskrivelse av en grense, ikke et løfte om enhver angriper.

Les funksjonslisten for utgivelsen du faktisk installerte, fordi sammensatte moduser ofte varierer mellom forbrukernivåer og noen ganger mangler på administrerte enheter. Sammenlign listen med feilen du ser før du antar at grensen holdt.

Stopp deretter og spør om feilen du jager i det hele tatt er lokal. Hvis betalingssiden vises feil bare i den beskyttede modusen, er miljøet den mistenkte og tunnelen irrelevant. Hvis den vises riktig overalt, men transaksjonen fortsatt mislykkes, ser du på neste grense, og å svekke den beskyttede modusen hjelper ikke.

Deretter: hvilken trafikk bærer tunnelen

En tunnel beskytter trafikken den dekker, og dekningen er et konfigurasjonsfaktum, ikke en produktegenskap. Spør om den beskyttede nettleserens egen trafikk er med, om modusen omgår tunnelen av ytelses- eller captive portal-grunner, og om en regel for delt tunnel utelukker målet. En vanlig nettleser som viser leverandørens utgangsadresse, beviser ingenting om et eget nettlesermiljø startet av en annen prosess.

Test dekningen fra innsiden av miljøet i stedet for fra skrivebordet. Last en side som viser din offentlige adresse i den beskyttede økten, og sammenlign den med adressen du ser utenfor, og gjenta etter å ha koblet til tunnelen på nytt. Hvis de to stemmer mens tunnelen hevder en annen utgang, bruker ikke modusen tunnelen, og avviket er verdt å løse før du taster inn kortopplysninger. Det er også lett å overtolke en endret utgangsadresse: den forteller hvilket nettverk forhandleren ser, ikke hvem forhandleren er.

Tredje: bekreft tjenesten i stedet for merket

Sertifikatvalidering er det som autentiserer målet, og det virker fortsatt etter tunnelutgangen fordi det er en egen mekanisme. Et beskyttet vindu med merkevare og en Connected-indikator sier ingenting om sertifikatkjeden nettstedet du nådde presenterer.

Når noe ser galt ut, les sertifikatet før du avviser advarselen. Kommandoen nedenfor ber om kjeden nettstedet faktisk presenterer, og ber verktøyet feile ved en valideringsfeil.

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

Sammenlign emnet og utstederen i den utskriften med adressen du skrev, og bekreft valideringsresultatet i stedet for tilstedeværelsen av en hengelås. En advarsel inne i en beskyttet nettleser er fortsatt en advarsel, og den vanlige årsaken er navneavvik på vert, en kapret DNS-respons eller en avlyttingsenhet på veien. Ingen av dem repareres av tunnelen, og en modus som stille undertrykker advarselen, har fjernet informasjon du trengte.

Fjerde: hva mottakeren likevel får vite

Betalingssiden mottar alt du sender til den: kontoen du logger på, leveringsadressen, kortinstrumentet og beløpet. En annen nettverksutgang endrer kildeadressen i forhandlerens logger og lar feltene være nøyaktig som de var. Hvis kontoen allerede er knyttet til deg, har tunnelen endret en liten del av bildet og ingenting av den identifiserende delen. Det er ikke grunn til å hoppe over tunnelen, bare grunn til å slutte å forvente at den gjør denne jobben.

Bitdefenders Safepay-dokumentasjon beskriver en beskyttet nettleser med tilhørende tunnelintegrasjon, som er et godt eksempel på ett produkt som dekker to grenser uten å smelte dem sammen. Både miljøet og veien er nyttige, og ingen av dem garanterer for forhandleren.

For en betaling du bryr deg om, start fra organisasjonens publiserte adresse eller dens offisielle applikasjon, behold identitetskontrollene nettstedet ber om, og avvis enhver hjelper som tilbys av en uventet ledetekst på betalingssiden. Hvis den beskyttede modusen eller tunnelen forårsaker en feil, navngi grensen først: starte miljøet, nå nettverket, validere sertifikatet eller autentisere kontoen. Bruk deretter leverandørens støttede gjenopprettingsvei for det laget i stedet for å slå av beskyttelse for å se om siden lastes.