Symmetric vs. public-key encryption sa VPN: ano ang ginagawa ng bawat isa

Inilalarawan ng mga tao ang VPN bilang „ang gumagamit ng public-key encryption“ at pagkatapos ay iniisip na bawat packet ay nakandado ng certificate ng server. Mali ang larawang iyon sa paraang mahalaga kapag nagbabasa ka ng config file o packet capture. Ang public-key na kalahati ng VPN ay tungkol sa pagpapatunay kung sino ang peer at pagkasundo sa lihim na materyal; ang symmetric na kalahati ang tunay na nagpoprotekta sa trapiko, packet after packet, sa buong buhay ng session.

Ang dalawang kalahati ay may magkaibang buhay, paraan ng pagpalya at mga bagay na ligtas na mailathala. Kapag hinati mo sila, ang mga tanong tulad ng „mas mahina ba ang RSA 2048 kaysa AES-128“ ay tumitigil sa pagkalito, dahil kailanman ay hindi sila maihahambing.

Tatlong operasyong pinagsasama-sama

Ang public-key cryptography ay isang payong sa ibabaw ng hindi bababa sa tatlong magkaibang operasyon. Pinatutunayan ng signature na inaprubahan ng may-ari ng private key ang isang partikular na mensahe. Pinapayagan ng key agreement ang dalawang peer na makakuha ng shared secret mula sa mga value na palitan nila nang hayagan. Itinatago ng public-key encryption ang data sa ilalim ng public key ng isang tao, kaya ang private key lang ang makakabukas.

Ang mga handshake ng VPN ay kadalasang gumagamit ng unang dalawa. Ang certificate ay hindi encryption key; ito ay pinirmahang pahayag na nagbubuklod ng pangalan sa isang public key at nagpapahintulot sa kabilang panig na magpasya kung pagkakatiwalaan ang key na katatanggap lang. Halimbawa, ang pagtatatag ng key sa TLS 1.3 ay nakabatay sa (EC)DHE key agreement at certificate signatures, hindi sa pag-encrypt ng session gamit ang public key ng server.

Ano talaga ang ginagawa ng handshake

Sa modernong handshake, gumagawa ang bawat panig ng ephemeral key pair, nagpapalitan ng public halves at nagkukuwenta ng shared secret na hindi kailanman dumadaan sa kawad. Dumadaan ang secret na iyon sa key derivation function upang makabuo ng hiwalay na key para sa bawat direksyon, kasama ang nonce at IV material na kailangan ng record layer. Ginagawa ito ng WireGuard sa konstruksiyon nitong nakabatay sa Noise; ginagawa ito ng TLS 1.3 sa HKDF sa transcript ng handshake.

Ang pangmatagalang credential — certificate at private key, o static na WireGuard key — ang nagpapatunay sa palitan na iyon. Pumipirma ito o humahalo sa transcript upang hindi makumpleto ng estranyo ang handshake kapalit ng peer. Pagkatapos, hindi na gumagawa ng trabaho ang credential sa bawat packet. Kung gagawa, mangangailangan ang bawat packet ng operasyon sa private key, at ang abalang tunnel ay malilimitahan ng pinakamabagal na operasyon sa stack.

Dalawang side effect ang sumusunod. Una, sariwa ang session key sa bawat pagkakataon, kaya ang attacker na magnanakaw ng pangmatagalang key mamaya ay hindi maaaring i-decrypt ang mga session na naitala noon, kung ephemeral ang kasunduan. Ikalawa, ang tumagas na session key ay nagko-compromise ng isang session, hindi ng identity.

Bakit gumagamit ng symmetric key ang malaking data

Mahusay na hinahawakan ng symmetric cipher ang volume: pinoproseso ng AES-GCM o ChaCha20-Poly1305 ang bawat packet gamit ang key na nasa memory na, ina-authenticate ang header at dinaragdagan ang counter. Sinusuri ng tumatanggap na panig ang nonce at authentication tag at itinatapon ang anumang pumalya o naulit. Sapat itong mura upang tumakbo sa bilis ng linya sa ordinaryong hardware, at ang parehong konstruksiyon ay nagbibigay ng confidentiality at integrity sa isang pass.

Ang konstruksiyon din ang lugar kung saan nakatira ang karamihan ng implementation bug. Ang paulit-ulit na nonce sa GCM ay sumisira sa confidentiality at authenticity nang sabay, kaya nagdederive ang protocol ng key kada direksyon at nagpapanatili ng malinaw na counter o epoch. Kung nagbabasa ka ng packet capture at ang haba ng ciphertext ay tumutugma sa plaintext dagdagan ng fixed na overhead, ang gumagana ay ang symmetric layer, hindi ang public-key operation kada packet.

Buhay, pag-ikot ng key at pagsulong na lihim

Ang mga session key ay nilalayong mag-expire. Pinapayagan ng TLS 1.3 ang KeyUpdate message na paikutin ang traffic key; nagre-renew ang WireGuard ng session pagkatapos ng nakatakdang oras o bilang ng mensahe at panandaliang hinahawakan ang luma para sa mga packet na nasa daan. Ang OpenVPN ay muling nakikipagnegosasyon sa key ng data channel nito ayon sa iskedyul, habang ang reneg-sec ang kumokontrol sa interval.

Wala sa mga rotation na iyon ang katulad ng pag-renew ng certificate. Ang certificate ay maaaring may bisa ng isang taon habang nagbabago ang session key kada ilang minuto, at ang certificate ay mapapalitan nang hindi hinahawakan ang key ng tumatakbong tunnel. Kapag nagpaplano ng expiry, itanong kung aling object ang iniikot mo; ang sagot ang magpapasya kung muling kokonekta ang client o magre-renew lang ng key.

Pagbasa ng config at diagnostics nang hindi pinaghahalo ang mga bagay

Sa praktika pumipili ka ng kumpletong protocol at ng mga primitibong sinusuportahan nito, hindi ka nagbubuo ng sarili mo. Pinoprotektahan ng --tls-crypt key ng OpenVPN ang control channel; gumagamit ang data channel ng negosyadong symmetric cipher. Ang PrivateKey at PublicKey entry ng WireGuard ay identity material, habang ang transport key nito ay hinahango sa loob. Ang pagbasa sa mga field na iyon bilang parehong uri ng secret ay humahantong sa mga pagkakamali tulad ng pagdikit ng public key kung saan dapat private key.

Panatilihing hiwalay ang public material sa private. Ligtas ibahagi sa ticket ang certificate, public key ng WireGuard at fingerprint. Ang private key, pre-shared key at na-export na session key ay hindi. Kapag naghahambing ng lakas, maghambing sa loob ng isang uri: elliptic curve identifier, laki ng RSA modulus at laki ng AES key may sinusukat na magkaibang bagay sa ilalim ng magkaibang palagay. Ang TLS 1.3 specification ay kapaki-pakinabang na sanggunian sa kung paano nagtutugma ang dalawang layer, kahit hindi TLS ang tunnel mo.