Hvis du besøker HTTPS-nettsteder og blir omdirigert uten advarsler, er problemet at nettleseren din ikke validerer sertifikatene riktig - en god nettleser vil vise en advarsel da portalsertifikatet ikke inneholder domenet du ønsket å besøke i dets vanlige navnefelt.

Et mulig sårbarhet ville være hvis du besøker nettstedet via HTTP, men det er løsninger for å redusere dette, for eksempel Secure Flag på informasjonskapsler som forteller nettleseren. ikke å sende denne informasjonskapselen over HTTP - og HSTS som gjør at nettleseren automatisk konverterer HTTP-forespørsler til nettstedet til HTTPS-forespørsler, i tillegg til at du forhindrer deg i å omgå sertifikatfeilen hvis en HTTPS-forbindelse ikke kan bli laget.

Atferden er avhengig av nettleseren. Hvis nettleseren faktisk sender HTTPS-forespørselen som er beregnet på Facebook til den internerte portalen, er det tydeligvis en nettlesersårbarhet. Men det er andre måter å håndtere situasjonen på.

Jeg har nylig måttet bruke et nettverk med en fangeportal et par ganger. Og i de tilfellene startet jeg Chromium som tilfeldigvis hadde et par Facebook-faner åpne fra en forrige økt.

Det som skjedde var at en riktig feilmelding ble vist. Men samtidig åpnet Chromium en ny fane som fikk tilgang til en spesifikk HTTP-URL med den faktiske intensjonen om å bli kapret av fangeportalen. Så snart jeg var forbi fangeportalen, lastes Facebook-fanene automatisk inn og denne gangen får det ikke feil.

Så det ser ut til at Chromium oppdager tilstedeværelsen av en fangeportal, åpner den trygt og til slutt oppdager når du er forbi fangeportalen.

Lignende fangeportaloppdagelse finnes i Android og iOS, selv om den ikke er knyttet til nettleseren, men heller skjer som en del av tilknytningen til tilgangspunktet. hr>

Jeg ser noen misforståelser i din forståelse av hvordan portaler i fangenskap fungerer. Fangeportalene jeg har kommet over fungerte absolutt på en annen måte.

Ingen avlytning ble gjort for DNS-trafikk. Så lenge du brukte DNS-serveren som ble levert gjennom DHCP, har datamaskinen din lov til å foreta DNS-oppslag uten begrensninger uten å ha fått tilgang til fangeportalen.

Ingen ICMP-triks blir trukket heller. Snarere vil en av ruterne på den legitime banen mellom datamaskinen din og serveren kapre TCP-tilkoblingene til port 80. Når TCP-forbindelsen er kapret, vil en viderekobling til fangeportalen bli sendt til nettleseren. I riktig implementering omdirigerer dette til en HTTPS-URL og inkluderer på en eller annen måte informasjon om den opprinnelige URL-en slik at du kan bli sendt tilbake dit senere. Hele kommunikasjonen med fangeportalen utføres ved hjelp av et legitimt sertifikat for et domenenavn som faktisk tilhører fangeportalen.

Denne tilnærmingen fungerer for HTTP - men ikke for HTTPS. Ruteren som utfører kapringen, vil ikke ha et gyldig sertifikat for nettstedet du besøker, så i en hvilken som helst sikker nettleser vil du få et sertifikatvarsel hvis den samme kapringen ble gjort for HTTPS.

Det er tre måter å omgå dette som ikke fungerer for HTTPS:

• Stol på at brukere ignorerer sikkerhetsadvarsler og godtar at deres private informasjon blir oppfanget, selv etter å ha blitt presentert for en veldig ordentlig advarsel om risikoen.
• Stol på at brukerne forstår hvordan det hele fungerer, og åpne alene en HTTP-URL for å bli kapret, og vet deretter å gå til den opprinnelige HTTPS-nettadressen etter å ha passert den fangede portalen.
• La klienten programvare oppdager tilstedeværelsen av fangede portaler og håndterer det på riktig måte. Dette er fortsatt avhengig av at brukerne kan oppdage om en portal i fangenskap prøver å utføre phishing-angrep, men i det minste ikke lekker noen informasjonskapsler.