Яагаад AES-256 нь VPN шифрлэлтийн багцыг дүрслэхгүй байна
Багц нь дөрвөн үүрэг гүйцэтгэдэг: бөөн шифрлэлт, бүрэн бүтэн байдал, түлхүүр тогтоох, эсрэг талыг баталгаажуулах. Шифрийн нэр нь тэдгээрийн зөвхөн нэгийг, нэг түвшинд хамардаг.
VPN ямар шифрлэлт хэрэглэдэг гэж асуухад хариулт ихэвчлэн нэг үгээр ирдэг: AES-256, эсвэл ChaCha20, эсвэл магадгүй WireGuard. Тэр хариулт нь нэг түвшний нэг бүрэлдэхүүнийг нэрлэдэг бол холболтыг үнэхээр хамгаалж байгаа зүйл нь дөрвөн өөр үүрэг гүйцэтгэдэг алгоритмын багц юм. Бүрэлдэхүүнийг зохион байгуулалттай андуурах нь эдгээр ярианы хамгийн түгээмэл алдаа бөгөөд шийдвэрлэх боломжгүй харьцуулалтыг үүсгэдэг.
Нэг холболтын доторх дөрвөн ажил
Бөөн шифрлэлт нь өгөгдлийн сувгийн хувьд тодорхой текстийг шифрлэгдсэн текст болгон хувиргадаг ба түүний түлхүүр нь дамжуулагдахгүй, үүсгэгддэг. Бүрэн бүтэн байдлын хамгаалалт нь өөрчлөлтийг илрүүлдэг бөгөөд энэ нь нэг бүтэц хоёуланг нь хийсэн ч тусдаа ажил юм. Түлхүүр тогтоох нь нийтлэг урсгалын материалыг бүрдүүлдэг бол эсрэг талыг баталгаажуулах нь нөгөө захад хэн байгааг шийддэг. Эдгээрийн аль нэг нь дутуу бол холболт аюулгүй биш, үлдсэн хэсэг нь хэчнээн хүчтэй байсан ч.
Зарим загвар хоёр үүргийг нэгтгэдэг. AES-GCM ба ChaCha20-Poly1305 нь баталгаажсан шифрлэлтийн бүтэц тул нууцлал ба бүрэн бүтэн байдал хамт ирдэг; AES-CBC тийм биш бөгөөд өөрийн түлхүүртэй тусдаа мессеж баталгаажуулах код шаарддаг. Тиймээс саналыг бие даасан тоонуудын уут гэж унших нь хосоор зохиогдсоныг буруу уншдаг.
Үүргүүд өөр өөр түвшинд байрладаг тул нэг үг хоёр бүтээгдэхүүнд өөр утга илэрхийлж болно. ESP доторх блок шифр ба TLS доторх блок шифр нь өөр шаардлагатай өөр хэлэлцээрт байгаа ижил примитив юм. Тиймээс примитивийг горим, түвшингүйгээр дурдах нь юу ч дурдахаас дор байж болно.
Яагаад шифрийн нэр бараг юу ч хэлдэггүй
AES-256 гэсэн хэллэгийг нэг мөч нухацтай авч үзье: энэ нь блок шифр ба түлхүүрийн хэмжээг заана. Энэ нь ажиллагааны горим, бүрэн бүтэн байдал өгөгдөж байгаа эсэх, түлхүүр хэрхэн тогтоогдсон эсвэл эсрэг тал хэрхэн баталгаажсаныг хэлдэггүй. Хоёр бүтээгдэхүүн хоёулаа AES-256 сурталчилж, бусад бүх зүйлээр ялгаатай байж болно, үүний дотор нэг нь баталгаажаагүй горимтой, нөгөө нь орчин үеийн түлхүүр солилцоотой AEAD горимтой.
TLS 1.3 энэ салангид байдлыг стандартад оруулсан бөгөөд энэ нь хуучин нэр томьёог сурсан хүн бүрт ашигтай засвар юм. Түүний шифрийн багцууд зөвхөн AEAD ба хэшийг нэрлэдэг бол түлхүүр солилцооны бүлгүүд, гарын үсгийн алгоритмууд тусдаа параметр хэлбэрээр хэлэлцэгддэг. Тиймээс TLS 1.3 багцын нэрийг TLS 1.2 багцын нэртэй тэнцүү үндэслэлээр харьцуулах боломжгүй, хоёулаа тохиргооны файлын нэг талбарт гарч байсан ч. Хоёр мөрийг шууд харьцуулж буй аудитор протокол дэмждэггүй дүгнэлтэд хүрдэг. Хэлэлцсэн бүлэг болон гарын үсгийн параметрүүдийг ч уншаарай, эс бөгөөс харьцуулалт дутуу.
WireGuard эсрэг замыг сонгож, хэлэлцээрийг бараг бүрэн арилгадаг: протокол тогтмол алгоритмын багцыг тодорхойлдог тул хоёр хэрэгжилт хамт ажиллана эсвэл үгүй. Энэ нь хууль ёсны загварын сонголт бөгөөд WireGuard ямар багц хэлэлцдэг вэ гэсэн асуултад харьцуулах үнэ цэнэтэй хариулт байхгүй гэсэн үг юм. Хэрэв та үүнийг аудит хийж байгаа бол, спецификацийг нэг удаа уншаад дараа нь түүний эргэн тойрны түлхүүрийн менежментийг аудит хийнэ үү, хэлэлцээрийг биш.
Түвшин нь нэр томьёог тодорхойлдог
IPsec байрлуулалт хоёр удаа хэлэлцдэг: хяналтын сувгийн IKE санал ба өгөгдлийн ESP хувиргалт, хоёулаа хууль ёсоор ялгаатай байж болно. Эхнийхийг уншаад хоёр дахьыг дүрсэлдэг гэж үзэх нь аудитын үеийн түгээмэл төөрөгдлийн эх сурвалж, учир нь тохиргооны файл хоёуланг нь дурдаж, сонирхолтой нь хоёр дахь нь.
| Layer | What is negotiated there | What it does not cover |
|---|---|---|
| IKE proposal | Algorithms and groups for the control channel that builds the tunnel | The algorithms protecting the data itself |
| ESP transform | Encryption and integrity for tunneled packets | Peer identity, which authentication already settled |
| TLS handshake | AEAD and hash, plus separately negotiated groups and signatures | Routing, authorization or retention policy |
| WireGuard | Nothing; the algorithm set is fixed by the protocol | Everything above the cryptographic arrangement |
Нэг сангийн дотор байгаа нэр нь өөр өгөгдлийн замд автоматаар хэрэгжихгүй. Тиймээс манай бүтээгдэхүүн AES-256-г дэмждэг гэсэн мэдэгдэл сонсогдохоос сул бөгөөд иймээс интероперабилити асуудлыг ихэвчлэн хоёр талд бүх хуучин алгоритмыг идэвхжүүлэх биш, харин хадгалагдсан огтлолцлыг олох замаар шийддэг.
TLS 1.3-ын спецификаци нь энэ салангид байдлын хамгийн тод нийтлэгдсэн жишээ, учир нь багцыг хос гэж тодорхойлж, үлдсэнийг өөрийн хэлэлцээр рүү шилжүүлдэг. Тэр хэлбэр танил болмогц IPsec санал ба WireGuard-ын нэг тогтмол багц нь ижил санааны хувилбар болж уншигдана.
Хэлэлцсэн үр дүнг уншаад дараа нь зогсоо
Тохируулсан санал нь хоёр тал юу сонгосны баталгаа биш. Амьд сесс хариултыг агуулдаг бөгөөд аливаа нийтлэг хэрэгжилт пакет барихгүйгээр түүнийг мэдээлж чадна.
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg showГаралт дээр санал болгосон жагсаалтыг биш, сонгосон алгоритмуудыг уншаарай. Хариулт бодлогоос сул бол засвар нь нэг талын саналын тохиргоонд байх бөгөөд орчин үеийн хэрэгжилтэд зөрүү нь ихэвчлэн чимээгүй бууралт биш, бүтэлгүй хэлэлцээр хэлбэрээр илэрдэг.
Дараа нь багц юуг хамардаггүйг санаарай. Маршрут, програмын зөвшөөрөл, бүртгэл, хадгалалт нь өөрийн хяналттай тусдаа шийдвэр бөгөөд нийцтэй криптограф зохион байгуулалт тэдний талаар юу ч хэлдэггүй. Шифрийн хэлэлцүүлэг нь үнэ цэнэтэй боловч ихэнх хүмүүсийн үнэхээр асуудаг асуултаас илүү нарийн асуултад хариулдаг.
Нэр томьёог нарийвчлан баривал маргаан богиносно. Багц бол түвшин дээрх үүргүүдийн багц, шифр бол нэг бүрэлдэхүүн, хэлэлцсэн үр дүн нь таны үнэхээр байгаа холболтыг дүрсэлдэг цорын ганц зүйл юм. Харьцуулалтын бусад бүх зүйл чимэглэл юм.