Симетрично и асиметрично криптиране във VPN: какво прави всяко
VPN удостоверява партньорите с публични ключове, после криптира пакетите с производни сесийни ключове. Третирайте сертификатите и ключовете за трафик като различни обекти.
Хората описват VPN като „използващ криптиране с публичен ключ“ и после си представят, че всеки пакет се заключва със сертификата на сървъра. Тази картина е грешна по начин, който има значение, когато четете конфигурационен файл или запис на пакети. Публичната половина на VPN се отнася до доказване кой е партньорът и договаряне на таен материал; симетричната половина е това, което реално защитава трафика, пакет след пакет, за целия живот на сесията.
Двете половини имат различен живот, различни режими на отказ и различни неща, които можете да публикувате безопасно. След като ги разделите, въпроси като „RSA 2048 по-слаб ли е от AES-128“ спират да заблуждават, защото те никога не са били сравними.
Три операции, които обикновено се смесват
Криптографията с публичен ключ е чадър над поне три различни операции. Подписът доказва, че притежателят на частен ключ е одобрил определено съобщение. Договарянето на ключ позволява на двама партньори да изведат споделена тайна от стойности, които разменят публично. Криптирането с публичен ключ скрива данни под чуж публичен ключ, така че само частният ключ може да ги отвори.
Ръкостисканията на VPN използват предимно първите две. Сертификатът не е ключ за криптиране; той е подписано твърдение, което свързва име с публичен ключ и позволява на другата страна да реши дали да се довери на ключа, който току-що е получила. Например, установяването на ключове в TLS 1.3 се гради на договаряне на ключ (EC)DHE плюс подписи на сертификати, а не на криптиране на сесията с публичния ключ на сървъра.
Какво всъщност произвежда ръкостискането
При модерно ръкостискане всяка страна генерира ефемерна двойка ключове, разменя публичните половини и изчислява споделена тайна, която никога не преминава по канала. След това тази тайна се прекарва през функция за извеждане на ключове, за да се получат отделни ключове за всяка посока, плюс nonce стойностите и материала IV, който записният слой се нуждае. WireGuard прави това със своята конструкция на базата на Noise; TLS 1.3 го прави с HKDF върху транскрипта на ръкостискането.
Дългосрочните удостоверения — сертификат и частен ключ или статичен ключ на WireGuard — удостоверяват тази размяна. Те подписват или се смесват в транскрипта, така че чужденец да не може да завърши ръкостискането на мястото на партньора. След това удостоверението не върши работа за всеки пакет. Ако вършеше, всеки пакет щеше да изисква операция с частен ключ и натоварен тунел щеше да се ограничава от най-бавната операция в стека.
Следват два странични ефекта. Първо, сесийните ключове са нови всеки път, поради което атакуващ, който по-късно открадне дългосрочния ключ, не може да декриптира по-рано записани сесии, при условие че договарянето е било ефемерно. Второ, изтекъл сесиен ключ компрометира една сесия, а не самоличността.
Защо големите данни използват симетрични ключове
Симетричните шифри се справят добре с обема: AES-GCM или ChaCha20-Poly1305 обработват всеки пакет с ключ, който вече е в паметта, удостоверяват заглавката и увеличават брояч. Приемащата страна проверява nonce и етикета за удостоверяване и изхвърля всичко, което се провали или се повтаря. Това е достатъчно евтино, за да работи с линейна скорост на обикновен хардуер, и същата конструкция дава поверителност и цялост за един проход.
Конструкцията е също мястото, където живеят повечето грешки в реализацията. Повторен nonce в GCM нарушава поверителността и автентичността наведнъж, затова протоколите извеждат ключове за всяка посока и поддържат явен брояч или епоха. Ако четете запис на пакети и дължината на шифротекста съвпада с отворения текст плюс фиксирана допълнителна задължителност, това работи симетричният слой, а не операция с публичен ключ за всеки пакет.
Живот, презареждане на ключове и предна тайна
Сесийните ключове са предназначени да изтекат. TLS 1.3 позволява съобщение KeyUpdate да превърта ключовете за трафик; WireGuard презарежда сесия след зададено време или брой съобщения и задържа старата за кратко за пакети по пътя. OpenVPN предоговаря ключовете на канала за данни по график, като reneg-sec контролира интервала.
Нито едно от тези превъртания не е същото като подновяване на сертификат. Сертификатът може да е валиден година, докато сесийните ключове се сменят на всеки няколко минути, и сертификатът може да бъде заменен, без да се пипат ключовете на работещия тунел. Когато планирате изтичане, питайте кой обект превъртате; отговорът решава дали клиентите ще се свържат отново, или просто ще сменят ключовете.
Четене на конфигурации и диагностика без смесване на обекти
На практика избирате цял протокол и поддържаните от него примитиви, а не сглобявате свой. Ключът --tls-crypt на OpenVPN защитава канала за управление; каналът за данни използва договорени симетрични шифри. Записите PrivateKey и PublicKey на WireGuard са материал за самоличност, докато транспортните му ключове се извеждат вътрешно. Четенето на тези полета като един и същ вид тайна води до грешки като поставяне на публичен ключ там, където принадлежи частен.
Държте публичния материал отделно от частния. Сертификат, публичен ключ на WireGuard и отпечатък са безопасни за споделяне в тикет. Частен ключ, предварително споделен ключ и експортиран сесиен ключ не са. Когато сравнявате сила, сравнявайте в рамките на един тип: идентификатор на елиптична крива, размер на RSA модул и размер на AES ключ мерят различни неща при различни допускания. Спецификацията на TLS 1.3 е полезен справочник за това как двата слоя се съчетават, дори когато тунелът ви не е TLS.