Kan eit nettverk blokkere VPN-en din utan å bryte krypteringa?
Kryptering verner innhaldet, ikkje leveringa. Samanlikn blokkeringslister, tillatingslister og nedstengingar, og spør deretter kva éin enkelt observasjon eigentleg kan grunngje.
Ingen operatør treng ein sesjonsnøkkel for å stoppe ein tunnel: kast pakkane på stien, og han feilar, medan kryptografien held seg nøyaktig så sterk som designet lova. Kryptering verner det ein samtale ber, ikkje viljen i eit gjeve nettverk til å bere det. Å skilje desse to eigenskapane gjer ein diskusjon om ublokkerbarheit til eit spørsmål om kva policy som gjeld, og kor langt ho rekk. Samanlikninga nedanfor held tilgjenge og konfidensialitet frå kvarandre, fordi dei fleste sjølvsikre påstandane om VPN-blokkering stille smeltar dei saman.
Tilgjenge er ei avgjerd som stien tek
Kvar transport er avhengig av ein sti som videresender pakkar, og kvart policyspørsmål her vert redusert til den videresendingsavgjerda. Ei regel som kastar pakkar, endrar tilgjenge utan å røre konfidensialiteten, og det er slik ein tunnel kan vere ulasteleg kryptert og fullstendig ubrukeleg i same augneblink. Ingenting ved det utfallet krev å bryte ein chiffre eller å gjenopprette ein nøkkel. Det krev berre kontroll over stien.
Forvirring startar vanlegvis med at to eigenskapar deler eitt ord. Sterk kryptografi handlar om kven som kan lese ein straum; ho seier ingenting om korvidt ein mellomliggjande boks slepp han gjennom. Påstanden om at ein VPN ikkje kan blokkerast treng derfor ein annan påstand under seg, nemleg at ingen på stien er viljug til å kaste pakkane.
Handhevingsstilar og prisen for kvar
Tre stilar dekkjer dei fleste verkelege policyar, og dei skil seg i kva dei må vite, kva dei kostar å drive og kven andre som lid. Kvar av dei kan avvise ein tunnel utan å dekryptere noko. Skilnadene tyder noko fordi det same ordet, blokkering, vert brukt om alle tre.
| Style | Default | What it must know | Who else is affected |
|---|---|---|---|
| Blocklist | Allow, minus listed destinations | Addresses and ports of known endpoints | Unrelated tenants on a listed address |
| Allowlist | Deny, plus approved destinations | A maintained definition of permitted traffic | Anything outside the approved set |
| Shutdown | Deny broadly for a period | Nothing about the protocol | Ordinary services along the same path |
Den tabellen er eit kostnadskart, ikkje ei rangering. Ei blokkeringsliste er billeg å starte og dyr å halde nøyaktig; ei tillatingsliste byter oppdaging mot vedlikehald av det tillatne settet, og ei nedstenging treng ingen klassifisering i det heile. Det som skil dei, er ikkje teknisk raffinement, men kvar kvar av dei legg den løpande innsatsen. Ein policy som ser enkel ut på papiret, har som regel ein skjult vedlikehaldspost ein annan stad.
Ei blokkeringsliste er avgrensa av kor godt ei adresse namngir ei teneste
Ei blokkeringsliste avviser destinasjonar som allereie er identifiserte, og lèt resten vere generelt tilgjengeleg. Å handheve ho krev adresser og portar, ikkje klartekst, og det er det som gjer ho billeg å drive i starten. Kostnaden kjem seinare, fordi eit område som ein gong identifiserte éin leverandør, kan enda med å huse eit dusin uvedkomande leigetakarar. Kvar adresseendring tvingar ei listendring, og kvar forelda oppføring tek uskuldig trafikk med seg.
Presisjon er på denne modellen avgrensa av kor godt ein destinasjon identifiserer ei teneste, og eit travelt delt endepunkt er ein dårleg identifikator. Det er ei strukturell grense og ikkje ein implementasjonsfeil, så betre verktøy fjernar ho ikkje. Det forklarer òg kvifor blokkeringslister har ein tendens til å vekse: kvart nytt endepunkt ser ut som eit lite tillegg, og følgjeskadane veks med lista.
Ei tillatingsliste flyttar vedlikehaldsbyrda
Ei tillatingsliste snur standarden, slik at berre dei førehandsvalde destinasjonane eller trafikktypane kan passere. Ho treng ikkje å ramse opp kvart forbode endepunkt, noko som hjelper når det forbode settet er stort eller endrar seg snøgt. Det ho treng i staden, er ein vedlikehalden definisjon av kva som er tillate, pluss handheving som passar til den definisjonen.
Portnummer er det vanlege svake punktet i ein slik definisjon. Å tillate ein port er ikkje det same som å identifisere kvart program som kan bruke han, så ei portbasert tillatingsliste slepp ofte gjennom meir enn forfattaren hadde tenkt. Protokollfingeravtrykk har same problemet frå ein annan vinkel, fordi dei identifiserer ei form for trafikk og ikkje ein hensikt. Ei tillatingsliste er derfor ikkje automatisk meir presis enn ei blokkeringsliste; ho er presis om noko anna.
Kva éin enkelt observasjon kan og ikkje kan grunngje
Ein kvar påstand om blokkering bør lesast med fire spørsmål i handa: kva tilgangsnettverk, kva destinasjonar, kva protokollar og kva observasjonsperiode. Ein feil som vert sett i dag på eitt mobilnett, seier ingenting om same endepunkt i morgon frå eit anna nett. Ein tunnel som verka éin gong, seier heller ingenting om varig tilgjenge.
Forma på ein feil kan observerast før du teoretiserer om årsaka. Eit stilt heng, ei augneblinkleg avvising og ein tilbakestilling etter tilkopling peikar på ulike handhevingsstilar, og to kommandoar skil dei:
curl -sS -m 8 https://vpn.example.com/ -o /dev/null -w "%{http_code}\n"
traceroute -n -m 8 vpn.example.comEit heng som endar i eit tidsavbrot, tyder på stille forkasting, ei snøgg avvising tyder på eit avvisande apparat på stien, og ein tilbakestilling etter tilkopling tyder på tilstandsbasert innblanding framfor ein manglande rute. RFC 9505-undersøkinga av sensurteknikkar skildrar kontrollpunkta og innblandingsmønstra bak desse formene. Ingen av dei fortel likevel kor breitt policyen gjeld. Varigheit er ein sterkare påstand enn tilgjenge: endepunkt, programvare, policyar og tillatne tenester endrar seg alle, så ubestemd effektivitet krev føresetnader om fortsett handheving og ikkje ei liste over adresser sette på eitt tidspunkt.