Jūsu tunelis ir ieslēgts, vienā cilnē redzama zaļa slēdzene, un vienkārša HTTP lapa citā cilnē joprojām brīdina, ka savienojums nav drošs. Šī kombinācija mulsina cilvēkus, jo abas aizsardzības sedz atšķirīgus attālumus. VPN aizsargā datu plūsmu starp saviem galapunktiem, un aiz izejas plūsma atkal kļūst parasta. HTTPS aizsargā vienu savienojumu līdz vietnei. Šo divu faktu salikšana kopā izskaidro lielāko daļu jautājumu par to, ko VPN patiešām slēpj.

Ko tunelis patiešām sedz

Starp klientu un VPN partneri novērotājs redz šifrētus baitus, nevis lasāmu pieprasījumu. Tas sedz posmu, kuru tunelis šķērso, un tas parasti ir tas posms, kuru jūs nepārvaldāt. Tas neattiecas uz savienojumu starp VPN izeju un vietni, jo tunelis beidzās izejā. Baiti atkal ir lasāmi no brīža, kad tunelis beidzas. Nekas šeit nav nepareiza konfigurācija.

Izeja ir mašīna, kas atšifrē un pārsūta, un tieši tam VPN ir paredzēts. Viss, ko tā pārsūta, tai ir redzams tādā formā, kādā tas tika saņemts, tāpēc vienkāršs HTTP pieprasījums no izejas paliek vienkāršs teksts.

Lasiet to kā īpašību, nevis kā defektu. Šifrēšana ir ierobežota ar vienu ceļu, un ceļš beidzas tur, kur sākas pakalpojums.

Atslēgas, nonce un integritāte vienkāršiem vārdiem

Notiekošā plūsma tiek aizsargāta ar simetrisko kriptogrāfiju, un abi gali roku saspišanas laikā atvasina vai iegūst atslēgas materiālu. Autentificētā šifrēšana, ko vispārīgi apraksta RFC 5116, nodrošina konfidencialitāti un integritāti vienā konstrukcijā. Uzņēmējs noraida mainītos baitus, nevis vienkārši nespēj tos nolasīt, un tieši to cilvēki aizmirst, domājot, ka šifrēšana nozīmē sajaukšanu.

Atslēgas nāk no šīs apmaiņas, nevis no pieteikšanās laikā ievadītās paroles. Parole autentificē identitāti, un tad protokols izveido sesijas materiālu. Efemēra atslēgu apmaiņa nodrošina uz priekšu vērstu slepenību, tāpēc ierakstīta sesija paliek nelasāma pat tad, ja vēlāk noplūst ilgtermiņa atslēga.

Liels skaitlis specifikācijā neatbild ne uz vienu no šiem jautājumiem, un skaitļu salīdzināšana starp nesaistītiem algoritmiem nav reitings. Tā vietā jautājiet, ko nodrošina atslēgu apmaiņa.

Kur tunelis beidzas

Galapunkts, kas pārtrauc tuneli, var nolasīt to, ko pārsūta. Tas vienlīdz attiecas uz uzņēmuma vārteju, komerciālu pakalpojumu sniedzēju un pašu mitinātu serveri. Tas ir dizains, nevis tā trūkums. Spēcīga kriptogrāfija nevar liegt kompromitētam galapunktam nolasīt vienkāršu tekstu, kas pie tā nonāk, jo aizsardzība apstājas tieši galapunktā.

HTTPS turpinās aiz šī punkta, tāpēc vietne var būt droša naidīgā tīklā arī bez VPN. Abas aizsardzības pārklājas pirmajā posmā, un pēc izejas turpinās tikai viena no tām.

Tāpēc sertifikāta verificēšanas vājināšana, lai savienojums darbotos, nav tuneļa tests. Tā izslēdz citu aizsardzību un atstāj jūs ar mazāk nekā sākumā.

Kāpēc anonimitāte ir cits produkts

Adreses, laiks un apjoms aiz tuneļa paliek novērojami. Novērotājs var redzēt, ka plūsma virzās uz VPN galapunktu, aptuveni cik daudz un kad. Saturs var būt nelasāms, kamēr modelis joprojām ir informatīvs.

Pakalpojumu sniedzējs arī atrodas citur nekā jūsu tīkls, un tas ir novērotāja maiņa, nevis novērošanas novēršana. Sīkfaili, pieteikšanās un konta identifikatori darbojas tieši tāpat kā iepriekš, jo tunelis nekad nav solījis tos mainīt.

Ja tā ir prasība, izvēlieties pakalpojumu sniedzēju pēc tā žurnālu politikas un jurisdikcijas, un tad izlasiet pašu politiku. Mārketinga lapas reti atbild uz šo jautājumu tā, lai kāds to varētu pārbaudīt.

Pārbaudiet tuneli un vietni atsevišķi

Vispirms pārbaudiet tuneli, lai zinātu, kuru aizsardzību jūs testējat. Pēc tam pārbaudiet pašas vietnes pārsūtīšanu un salīdziniet abus rezultātus, tā vietā lai pieņemtu, ka viens nozīmē otru. Tunelis, kas pārsūta vienkāršu HTTP, un vietne, kas nodrošina HTTPS, abi dara tieši to, kam tie tika konfigurēti.

Veiciet pārbaudes pret resursdatoru, kuru jums ir atļauts testēt, un lasiet izvadi, nevis kopsavilkumu.

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

Kad tunelis ir ieslēgts un vietne ir HTTPS, pirmajā posmā jums ir divas aizsardzības, bet otrajā ir viena. Kad vietne ir vienkāršs HTTP, otrais posms ir lasāms ikvienam tajā, tostarp izejai, kas pārsūtīja pieprasījumu. Zināšana, kuras no abām trūkst, ir visa diagnoze, un tam vajadzīgas divas komandas, nevis jauns klients.

Saistītie raksti