Kion la tunelo ĉifras kaj kion ĝi lasas legebla

Via tunelo funkcias, unu langeto montras verdan seruron, kaj ordinara HTTP-paĝo en alia langeto ankoraŭ avertas, ke la konekto ne estas sekura. Tiu kombino konfuzas homojn, ĉar la du protektoj kovras malsamajn distancojn. VPN protektas trafikon inter siaj propraj finpunktoj, kaj preter la eliro la trafiko denove estas ordinara. HTTPS protektas unu konekton ĝis la retejo. Meti tiujn du faktojn unu apud la alia klarigas plej multajn demandojn pri tio, kion VPN vere kaŝas.

Kion la tunelo efektive kovras

Inter la kliento kaj la VPN-partnero observanto vidas ĉifritajn bitokojn anstataŭ legeblan peton. Tio kovras la segmenton, kiun la tunelo trapasas, kiu kutime estas la parto, kiun vi ne kontrolas. Ĝi ne etendiĝas al la ligo inter la VPN-eliro kaj la retejo, ĉar la tunelo finiĝis ĉe la eliro. La bitokoj denove estas legeblaj de la momento, kiam la tunelo finiĝas. Nenio en tio estas misagordo.

La eliro estas maŝino, kiu malĉifras kaj plusendas, kaj ĝuste por tio VPN ekzistas. Ĉio, kion ĝi plusendas, estas videbla al ĝi en la formo, en kiu ĝi ricevis ĝin, do ordinara HTTP-peto restas ordinara teksto de la eliro antaŭen.

Legu tion kiel econ, ne kiel difekton. Ĉifrado limiĝas al vojo, kaj la vojo finiĝas tie, kie la servo komenciĝas.

Ŝlosiloj, nonce kaj integreco per simplaj vortoj

Daŭra trafiko estas protektata per simetria kriptografio, kaj ambaŭ flankoj derivas aŭ akiras la ŝlosilmaterialon dum la manpremo. Aŭtentigita ĉifrado, priskribita ĝenerale en RFC 5116, donas konfidencon kaj integrecon en unu konstruo. La ricevanto malakceptas ŝanĝitajn bitokojn anstataŭ simple malsukcesi legi ilin, kaj ĝuste tion homoj forgesas, kiam ili pensas, ke ĉifrado signifas miksadon.

Ŝlosiloj venas el tiu interŝanĝo, ne el la pasvorto tajpita ĉe ensaluto. La pasvorto aŭtentigas identecon, kaj poste la protokolo starigas seancleran materialon. Efemera ŝlosilinterŝanĝo donas antaŭen-sekreton, do registrita seanco restas nelegebla eĉ se longtempa ŝlosilo poste likas.

Granda nombro en specifikaĵo respondas al neniu el tiuj demandoj, kaj kompari nombrojn inter senrilataj algoritmoj ne estas rango. Demandu anstataŭe, kion la ŝlosilinterŝanĝo donas.

Kie la tunelo finiĝas

La finpunkto, kiu finas la tunelon, povas legi tion, kion ĝi plusendas. Tio validas same por kompania enirejo, komerca provizanto kaj memgastigita servilo. Ĝi estas la dezajno, ne difekto en ĝi. Forta kriptografio ne povas malhelpi kompromititan finpunkton legi ordinaran tekston, kiu alvenas al ĝi, ĉar la finpunkto estas loko, kie la protekto haltas.

HTTPS daŭras preter tiu punkto, tial retejo povas esti sekura en malamika reto eĉ sen VPN. La du protektoj interkovriĝas sur la unua segmento kaj nur unu el ili daŭras post la eliro.

Tial ankaŭ malfortigi atestilan kontroladon por ke konekto funkciu ne estas testo de la tunelo. Ĝi malŝaltas alian protekton kaj lasas vin kun malpli ol vi havis komence.

Kial anonimeco estas alia produkto

Adresoj, tempo kaj volumeno restas observeblaj ekster la tunelo. Observanto povas vidi, ke trafiko fluas al VPN-finpunkto, proksimume kiom, kaj kiam. Enhavo povas esti nelegebla dum la ŝablono ankoraŭ informas.

La provizanto ankaŭ sidas aliloke ol via propra reto, kio estas ŝanĝo de observanto, ne forigo de observado. Kuketoj, ensalutoj kaj kontaj identigiloj daŭre funkcias same kiel antaŭe, ĉar la tunelo neniam promesis ŝanĝi ilin.

Elektu provizanton laŭ ĝia protokolada politiko kaj jurisdikcio, se tio estas la postulo, kaj poste legu la politikon mem. Merkatadaj paĝoj malofte respondas tiun demandon tiel, ke iu povu kontroli ĝin.

Kontrolu la tunelon kaj la retejon aparte

Unue kontrolu la tunelon, por ke vi sciu, kiun protekton vi testas. Poste kontrolu la propran transporton de la retejo kaj komparu la du rezultojn anstataŭ supozi, ke unu implicas la alian. Tunelo, kiu portas ordinaran HTTP, kaj retejo, kiu servas HTTPS, ambaŭ faras ĝuste tion, por kio ili estis agorditaj.

Rulu la kontrolojn kontraŭ gastiganto, kiun vi rajtas testi, kaj legu la eligon anstataŭ la resumon.

wg show
ip -brief addr show tun0
curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' https://example.com

Kiam la tunelo funkcias kaj la retejo estas HTTPS, vi havas du protektojn sur la unua segmento kaj unu sur la dua. Kiam la retejo estas ordinara HTTP, la dua segmento estas legebla de ĉiu ajn en ĝi, inkluzive de la eliro, kiu plusendis la peton. Scii, kiu el la du mankas, estas la tuta diagnozo, kaj ĝi postulas du komandojn anstataŭ novan klienton.