Mida tunnel krüpteerib ja mida loetavaks jätab
Tunnel peidab sisu oma otspunktide vahel ega midagi kaugemal. Võtmed, terviklikkus ja otspunktid otsustavad ülejäänu ning HTTPS teeb endiselt oma tööd.
Teie tunnel töötab, üks vahekaart näitab rohelist lukku ja teise vahelehe tavaline HTTP-leht hoiatab endiselt, et ühendus ei ole turvaline. See kombinatsioon ajab inimesi segadusse, sest kaks kaitset katavad erinevat vahemaad. VPN kaitseb liiklust oma otspunktide vahel ja väljapääsu taga on liiklus taas tavaline. HTTPS kaitseb ühte ühendust kuni veebisaidini. Nende kahe fakti kõrvutamine seletab enamiku küsimusi sellest, mida VPN tegelikult peidab.
Mida tunnel tegelikult katab
Kliendi ja VPN-partneri vahel näeb vaatleja krüpteeritud baite, mitte loetavat päringut. See katab lõigu, mille tunnel läbib, ja see on tavaliselt osa, mida te ei kontrolli. See ei ulatu VPN-i väljapääsu ja veebisaidi vahelise lülini, sest tunnel lõppes väljapääsus. Baidid on taas loetavad hetkest, mil tunnel lõpeb. Selles ei ole midagi vale konfiguratsiooni.
Väljapääs on masin, mis dekrüpteerib ja edastab, ja täpselt selleks ongi VPN. Kõik, mida see edastab, on sellele nähtav kujul, milles see vastu võeti, seega tavaline HTTP-päring jääb väljapääsust alates lihtsaks tekstiks.
Lugege seda omadusena, mitte defektina. Krüpteerimine on piiratud teekonnaga ja teekond lõpeb seal, kus algab teenus.
Võtmed, nonce'id ja terviklikkus lihtsas keeles
Jooksev liiklus on kaitstud sümmeetrilise krüptograafiaga ning mõlemad otsad tuletavad või hangivad võtmematerjali käepigistuse käigus. Autentitud krüpteerimine, mida RFC 5116 üldiselt kirjeldab, annab konfidentsiaalsuse ja terviklikkuse ühes konstruktsioonis. Vastuvõtja lükkab muudetud baidid tagasi, selle asemel et lihtsalt mitte suuta neid lugeda, ja just selle unustavad inimesed, kui arvavad, et krüpteerimine tähendab segamist.
Võtmed tulevad sellest vahetusest, mitte sisselogimisel trükitud paroolist. Parool autendib identiteedi ja seejärel loob protokoll seansi materjali. Efemeerne võtmevahetus annab edasisuunalise saladuse, seega salvestatud seanss jääb loetamatuks ka siis, kui pikaajaline võti hiljem lekib.
Suur arv spetsifikatsioonis ei vasta ühelegi neist küsimustest ja arvude võrdlemine mitteseotud algoritmide vahel ei ole edetabel. Küsige selle asemel, mida võtmevahetus pakub.
Kus tunnel lõpeb
Otspunkt, mis tunnelit lõpetab, saab lugeda seda, mida edastab. See kehtib võrdselt ettevõtte lüüsi, äriühingust pakkuja ja isemajutatava serveri kohta. See on disain, mitte defekt selles. Tugev krüptograafia ei saa takistada kompromiteeritud otspunkti lugemast lihtteksti, mis selleni jõuab, sest otspunkt on koht, kus kaitse lõpeb.
HTTPS jätkub sellest punktist kaugemale, seepärast võib sait olla vaenulikus võrgus turvaline ka ilma VPN-ita. Kaks kaitset kattuvad esimesel lõigul ja pärast väljapääsu jätkub neist ainult üks.
Seepärast ei ole sertifikaadi kontrollimise nõrgendamine, et ühendus töötaks, tunnelitest. See lülitab välja teise kaitse ja jätab teid vähemaga, kui alguses oli.
Miks anonüümsus on teine toode
Aadressid, ajastus ja maht jäävad väljaspool tunnelit vaadeldavaks. Vaatleja näeb, et liiklus liigub VPN-i otspunkti, umbkaudu kui palju ja millal. Sisu võib olla loetamatu, samal ajal kui muster on endiselt informatiivne.
Pakkuja asub ka teie enda võrgust erinevas kohas, mis on vaatleja vahetus, mitte vaatluse eemaldamine. Küpsised, sisselogimised ja konto identifikaatorid töötavad täpselt nagu enne, sest tunnel ei lubanud neid kunagi muuta.
Kui nõue on see, valige pakkuja tema logimispoliitika ja jurisdiktsiooni järgi ning lugege siis poliitikat ennast. Turunduslehed vastavad sellele küsimusele harva nii, et keegi saaks seda kontrollida.
Kontrollige tunnelit ja saiti eraldi
Kõigepealt kontrollige tunnelit, et teaksite, millist kaitset testite. Seejärel kontrollige saidi enda transporti ja võrrelge kahte tulemust, selle asemel et eeldada, et üks tähendab teist. Tavalisel HTTP-l põhinev tunnel ja HTTPS-i pakkuv sait teevad mõlemad täpselt seda, milleks need seadistati.
Käivitage kontrollid hosti vastu, mida tohib testida, ja lugege väljundit, mitte kokkuvõtet.
wg show
ip -brief addr show tun0
curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' https://example.comKui tunnel töötab ja sait on HTTPS, on teil esimesel lõigul kaks kaitset ja teisel üks. Kui sait on tavaline HTTP, on teine lõik loetav kõigile sellel viibijatele, kaasa arvatud väljapääs, mis päringu edastas. Teadmine, milline kahest puudub, on kogu diagnoos ja selleks on vaja kahte käsku, mitte uut klienti.