Er hotell-Wi-Fi trygt? Det korte svaret
Hotell-Wi-Fi er rimelig trygt for vanlig bruk på en oppdatert Mac, og betydelig tryggere enn det ryktet tilsier. Den klassiske advarselen, at noen to rom unna leser passordene dine ut av luften, er nærmest utdatert: nesten all trafikk som betyr noe er kryptert ende-til-ende før den forlater maskinen din, og macOS pluss en oppdatert nettleser håndterer det uten at du trenger å gjøre noe.
Det er den enkle versjonen. Nyanser er at kryptering beskytter innhold, ikke kontekst. Ingen på hotellnettverket leser e-posten din, men nettverket kan fortsatt se at Mac-en din kontaktet en bestemt e-postleverandør, en bestemt cloud drive, og en bestemt VPN-tjeneste, klokken 06:40 om morgenen, hver morgen, i fem dager. Over et langt opphold legger dette opp til en atferdsprofil, og ingen av delene krever at du bryter en enkelt forbindelse.
To ting skiller et hotell fra en kafé. Den første er identitet: innloggingssiden spør vanligvis etter etternavn og romnummer, slik at operatøren kan koble hver enhet og tilkobling til en navngitt gjest i stedet for en anonym person med kaffe. Den andre er varighet: et kafébesøk varer i førti minutter, et hotellopphold er dager med automatisk tilkobling og bakgrunnssynkronisering som kjører mens du er et sted langt unna maskinen.
Så den ærlige trusselmodellen er ikke avlytting av hemmeligheter. Det er tre andre ting: en Mac eksponert for et flatt nettverk fullt av fremmede i dager, en detaljert trafikklogg knyttet til navnet ditt, og muligheten for å koble til et nettverk som bare ser ut som hotellets. Alle tre har enkle svar, og ingen av dem krever panikk.
Hva gjør et hotellnettverk annerledes enn andre offentlige Wi-Fi
Alle i bygningen er på ett flatt nettverk. Hotellgjest-Wi-Fi er ofte implementert uten klientisolasjon, noe som plasserer gjesten i rom 412 og gjesten i rom 118 på samme kringkastingsdomene som deg. Mac-en din annonserer seg selv over Bonjour med det navnet du ga den, ofte ditt virkelige fornavn og maskinmodell, og enhver delingstjeneste som er aktivert fra et tidligere prosjekt er tilgjengelig for alle andre. Noen kjeder isolerer klienter ordentlig, men du kan ikke se hvilke fra utsiden, så anta at de ikke gjør det.
Den kapte portal binder trafikk til en gjestetilgang. Romnummer og etternavn, noen ganger et lojalitetsnummer eller en e-postadresse for den raskere tjenesten. Det er ikke ondt ment; det er slik hotellet håndhever én konto per rom, og i flere jurisdiksjoner er operatøren forpliktet til å beholde tilkoblingslogger uansett. Det betyr bare at uttrykket anonymt offentlig nettverk ikke gjelder her. Uansett hva nettverket registrerer, registrerer det mot deg med navn.
Utstyret er ofte gammelt og sjelden vedlikeholdt. Hotell-Wi-Fi installeres vanligvis én gang av en entreprenør, administreres eksternt, og forlates i årevis fordi det fungerer. Adgangspunkt og gateway-enheter oppdateres sjelden, firmware ligger flere versjoner bak, og standardkonfigurasjoner forblir. Dette er ikke et angrep i seg selv, men det betyr at nettverkets egne beskyttelser, inkludert den isolasjonen som brosjyren lovet, kan være feilkonfigurert eller rett og slett ødelagt.
Portaler forstyrrer DNS med vilje. For at innloggingssiden skal vises i det hele tatt, må gatewayen fange opp dine første forespørsler og omdirigere dem, noe som betyr å avlytte DNS. Noen portaler fortsetter å gjøre dette etter at du har autentisert, og noen løser navn til sine egne svar for hele oppholdet. Dette er også grunnen til at kryptert DNS skaper problemer på hoteller: hvis Mac-en din er satt til en privat DNS-profil eller en egendefinert resolver, kan portalen ofte ikke omdirigere deg, og innloggingssiden lastes aldri, noe som er den vanligste klagen på hotell-Wi-Fi.
Og så blir du værende. Auto-tilkobling betyr at Mac-en kobler seg til igjen hver gang lokket åpnes uten å spørre. Multipliser den normale bakgrunnsaktiviteten til macOS og et dusin installerte apper med fire eller fem dager av det, og eksponeringen er ikke en enkelt økt på et utro tjenestested, men en kontinuerlig opphold på nettverket.
Hva HTTPS allerede dekker, og metadataene det ikke gjør
Start med de gode nyhetene, fordi de er betydelige. HTTPS krypterer innholdet i en tilkobling: sidens innhold, skjemaer, passord, meldingskropper, API-forespørsler. Nettlesere bruker nå som standard HTTPS og nekter å nedgradere stille, TLS 1.3 er normen, og de fleste Mac-apper krypterer sin egen trafikk. Noen som sitter på hotellets nettverk med en pakkesniffing ser kryptert data. Den gamle trikken med å hente innloggingsinformasjon fra et åpent nettverk fungerer ikke lenger.
Det HTTPS ikke skjuler er faktum og form på hver enkelt tilkobling. Destinasjons-IP-adressen er alltid synlig, fordi pakkene må rutes. DNS-oppslag er synlige med mindre du bruker kryptert DNS, noe portaler ofte blokkerer. Servernavnet i TLS-handshake er synlig på de fleste tilkoblinger i dag, siden Encrypted Client Hello fortsatt er langt fra universelt. Og tid, størrelse og frekvens på hver utveksling er synlig for alle på veien, uansett hvor sterk krypteringen er.
Sammenstilt over flere netter, er denne metadataen mer avslørende enn folk forventer. Den viser hvilke tjenester du bruker, når du våknet, når du forlot bygningen og kom tilbake, hvor lenge videokallene dine varte, og hvilket nettverk arbeidsgiveren din brukte. En e-postklient som sjekker hver femte minutt er et presist tilstedeværelsessignal. Ingen av disse krever å lese en eneste melding. Metadata er den virkelige eksponeringen på et hotellnettverk, ikke innholdet.
Det finnes også en rest av trafikk som ikke er beskyttet i det hele tatt. Noen eldre eller forlatte apper sjekker fortsatt for oppdateringer over vanlig HTTP, og lokal nettverksoppdagelse er ukryptert av natur, så mDNS og Bonjour-broadcasts annonserer enhetsnavnet ditt og tjenestene til hele gjestenettverket. Printeroppdagelse, mediedeling og alt som forventer et betrodd hjemmenettverk oppfører seg nøyaktig på samme måte på et hotell, fordi Mac-en din ikke har peiling på at nettverket har endret karakter.
Den ene situasjonen hvor HTTPS virkelig svikter er når en person overstyrer det. Hvis et sertifikatvarsel vises, ikke klikk på det, og hvis noe nettverk ber deg installere en profil eller et rotsertifikat før tilgang, avvis det og bruk mobilnett i stedet. Et hotell trenger romnummeret ditt for å la deg komme på nettet. Det trenger ikke evnen til å utstede sertifikater som Mac-en din vil stole på.
Hva du faktisk bør gjøre, i rekkefølge etter effekt
Hold Mac-ens brannmur på og del ingenting. Dette er det mest verdifulle steget fordi det retter seg direkte mot det flate nettverket. Slå på brannmuren under Systeminnstillinger, Nettverk, Brannmur, og aktiver stealth-modus i innstillingene slik at Mac-en ikke svarer på uønskede forespørsler. Åpne deretter Systeminnstillinger, Generelt, Deling og bekreft at Fildeling, Skjermdeling, Skriverdeling, Ekstern pålogging og Fjernadministrasjon er av, og sett AirDrop til Bare kontakter. Merk hva macOS-brannmuren ikke gjør: den filtrerer bare innkommende tilkoblinger, og ingenting i den begrenser hva dine egne apper sender ut.
Kutt bakgrunnssynkronisering for oppholdets varighet. Slå på Low Data Mode for hotellnettverket spesielt, under Systeminnstillinger, Wi-Fi, Detaljer ved siden av nettverket du koblet til. Det stopper pålitelig Apples egen bakgrunnsarbeid: nedlastinger av programvareoppdateringer, nedlastinger fra App Store, iCloud Photos-synkronisering og ulike utsettede oppgaver. For tredjepartsapper er det bare et rådgivende flagg som mange utviklere aldri implementerte, så avslutt eller sett på pause for dine skyløsninger og sett Time Machine til å ta sikkerhetskopi manuelt. Mindre bakgrunnstrafikk betyr mindre metadata og færre overraskelser hvis hotellet måler eller begrenser tilkoblingen.
Bruk en VPN for krypteringen du ellers ikke får. En VPN pakker alt, inkludert DNS og tilkoblingsmetadata nevnt ovenfor, inn i en enkelt tunnel til en enkelt adresse, slik at den detaljerte tidslinjen kollapser til en kryptert økt. To ærlige advarsler: du flytter tilliten fra hotellet til VPN-operatøren i stedet for å eliminere den, så velg en med en loggpolicy du faktisk har lest, og en VPN stopper ikke noen app fra å koble til. Den endrer veien, ikke deltakerne. Koble den til etter at du har passert captive-portalen, og slå på en kill switch hvis klienten tilbyr en.
Bestem hvilke apper som kan nå nettverket i det hele tatt. Dette er delen en VPN ikke kan gjøre. Kryptering handler om transport; appkontroll handler om omfang. På et nettverk du skal være på i flere dager, har det meste av det som er installert på Mac-en din ingen grunn til å snakke: en nettleser, en e-postklient og VPN-klienten dekker vanligvis alt du har tenkt å gjøre. Alt annet kan forbli stille til du sjekker ut, noe som reduserer både metadata-sporet og antallet prosesser som er eksponert for det som ellers er på det nettverket.
Bli med på riktig nettverk, og forlat det riktig. Spør resepsjonen om det eksakte nettverksnavnet i stedet for å gjette ut fra listen, fordi et falskt tilgangspunkt som sender ut et troverdig hotellnavn koster nesten ingenting å sette opp og er en av de få ekte, vanlige angrepene som fortsatt finnes. Behandle et hotellmerket nettverk uten portal, eller en portal som ber om kortnummer i stedet for romnummer og etternavn, som en grunn til å stoppe. Foretrekk et gjestenettverk med WPA2- eller WPA3-passord over et helt åpent. Ved utsjekk, åpne Systeminnstillinger, Wi-Fi, Detaljer og velg Glem dette nettverket, ellers vil Mac-en din stille og rolig koble til igjen hvilket som helst nettverk med det navnet over hele verden.
Kontrollere hva Mac-en din gjør mens du sover
Lukket lokk er ikke det samme som å være offline. macOS vekker seg periodisk for nettverkstilgang, kjører planlagt vedlikehold, sjekker etter oppdateringer, og lar apper oppdatere i bakgrunnen. Over fire netter er det hundrevis av tilkoblinger du aldri startet, gjort mens du sov eller var ute, på et nettverk du ville kalt ubetrodd hvis noen spurte. Ingenting av dette er ondsinnet. Det er macOS som antar at hvert Wi-Fi-nettverk er ditt eget, noe som er riktig standard hjemme og feil i rom 412.
Derfor er per-app kontroll den riktige løsningen på dette problemet. En VPN krypterer tunnelen, men hver app snakker fortsatt, og Low Data Mode spør høflig mens mange apper avviser. Det som faktisk reduserer eksponeringen er å bestemme, før du kobler til, hvilke få apper som skal ha lov til å kommunisere, og å ha denne beslutningen automatisk anvendt i stedet for å huske den hver kveld.
Dette er grunnen til at NetMute er bygget for. Dets hotspot-beskyttelse oppdager at du har koblet til et ukjent eller ubetrodd nettverk og bruker umiddelbart en streng profil, uten å vente på at du skal tenke på det, og håndterer captive portals slik at hotellinnloggingssiden fortsatt lastes inn i stedet for å bli blokkert sammen med alt annet. Nettverksprofiler er knyttet til Wi-Fi-navnet, så hotellprofilen kommer tilbake av seg selv neste gang du sjekker inn på det nettverket, og din vanlige hjemmeprofil returnerer når du kommer hjem.
Dag for dag forblir kontrollene enkle. Ethvert program kan blokkeres med ett klikk, midlertidige regler utløper av seg selv, så å la en oppdaterer kjøre i ti minutter ikke etterlater et permanent hull, og hviteliste-modus inverterer hele systemet: ingenting når ut til nettverket unntatt det du har navngitt. Hvis hotellet måler eller begrenser tilkoblingen, begrenser per-app datagrense de som er skyldige før de blir et problem.
Det folk synes er mest nyttig etter en tur er bevisene. Den sanntids trafikkmonitoren og domenenivå-logg svarer på spørsmålet dette hele artikkelen handler om: hva som faktisk snakket mens du sov. Det er verdt å sjekke én gang, fordi listen vanligvis er lengre enn man forventer, og det gjør neste oppholds profil enkel å skrive.