Një certifikatë VPN e personalizuar nuk është shtresë shtesë kriptimi

Instalimi i një certifikate të personalizuar në një pikë fundore VPN duket si shtim mbrojtjeje, sepse certifikatat dhe kriptimi shfaqen kudo bashkë. Në praktikë ndryshon dy gjëra: çfarë identiteti paraqet pika fundore dhe cilit lëshues pala tjetër është e gatshme t'i besojë. Asnjëra prej tyre nuk i mbështjell të dhënat tuaja për herë të dytë. Nëse nevoja reale është një kanal i dytë i mbrojtur, ju nevojitet një kanal i dytë me pikat e veta fundore, jo një certifikatë tjetër.

Tre detyra të ndara në një shtrëngim duarsh TLS 1.3

RFC 8446 i mban këto të ndara, dhe vetë kjo ndarje është e gjithë përgjigjja. Mesazhi Certificate mbart zinxhirin e certifikatave të pikës fundore. CertificateVerify provon zotërimin e çelësit privat përkatës dhe lidh transkriptin e shtrëngimit të duarve. Shtresa e regjistrave mbron trafikun me çelësat e trafikut të negociuar.

Zëvendësoni certifikatën dhe dy pikat e para ndryshojnë. Mbrojtja e regjistrave nuk ekzekutohet dy herë dhe nuk bëhet më e fortë sepse lëshuesi tani është privat.

Çfarë blen në të vërtetë një CA private

Blennjë sistem identiteti të kontrolluar: ju vendosni kujt i lëshohet, ju vendosni cilat lëshues pranojnë palët, dhe mund të revokoni sipas kalendarit tuaj. Kjo është vërtet e dobishme kur administroni të dy skajet.

Por sjell edhe detyrime. Besimi duhet të shpërndahet me qëllim, verifikimi i palës duhet të mbetet i ndezur, dhe cikli i jetës së kredencialeve duhet të ketë një pronar. Një CA private nuk është shkurtore për të anashkaluar asnjë nga këto tri.

Kur kanali i dytë është përgjigjja e saktë

Supozoni se një aplikacion hap HTTPS të verifikuar drejt shërbimit të vet, ndërsa paketat e tij kalojnë edhe nëpër VPN. Ai dizajn ka dy kufij me pika fundore potencialisht të ndryshme, dhe kështu duket një kanal i dytë i mbrojtur.

Dallimi ka rëndësi në portë. Nëse sesioni TLS i aplikacionit përfundon në portën VPN dhe jo në aplikacion, mbrojtja që mendonit se kishit përtej tunelit nuk është aty. Shkruani kush e përfundon çdo kanal përpara se ta pretendoni këtë veti.

Pyetni çfarë ndryshon instalimi

Një kërkesë për të instaluar një certifikatë mund të nënkuptojë tri gjëra të ndryshme. Mund të ndryshojë identitetin e vetë klientit, një ankorë besimi specifike për aplikacionin, ose besimin në nivel platforme për gjithçka në pajisje. Këto nuk janë ekuivalente, dhe vetëm e fundit ndikon në software të palidhur.

Pyetni cila nga të tria është e synuar, pastaj pyetni çfarë duhet të arrijë. Nëse përgjigjja është më shumë kriptim, propozimi është i drejtuar drejt mekanizmit të gabuar.

Shkruani kufijtë

Për çdo kanal, regjistroni pikat fundore, identitetin që verifikon secila anë dhe çfarë mund të shohë operatori në mes. Pastaj regjistroni sjelljen në dështim: çfarë ndodh kur verifikimi dështon, dhe çfarë ndodh kur kanali refuzohet.

Dy rreshta në një faqe zakonisht zgjidhin një debat që një rrotullim certifikatash nuk mund ta zgjidhë.

Vendosni me tri pyetje

A është problemi kush pretendon të jetë pika fundore, apo çfarë ndodh me të dhënat? A duhet mbrojtja të vazhdojë përtej portës VPN deri në një aplikacion të caktuar? Dhe a mund të përmendni dy pikat fundore që do të përfundonin një kanal të dytë?

Nëse pyetja e parë është ajo e vërteta, rregulloni identitetin dhe besimin. Nëse është e dyta ose e treta, projektoni kanalin e dytë dhe lëreni certifikatën aty ku i takon.