Защо 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В изхода четете избраните алгоритми, а не предложения списък. Ако отговорът е по-слаб от предвиденото в политиката, поправката е в конфигурацията на предложението от една от страните, а несъответствието в модерните реализации обикновено изглежда като неуспешни преговори, а не като тихо понижаване.
После помнете какво наборът не покрива. Маршрути, разрешения за приложения, журналиране и съхранение са отделни решения със свой преглед и съвместимата криптографска подредба не казва нищо за тях. Разговорът за шифъра си струва, но отговаря на по-тесен въпрос от този, който повечето хора всъщност задават.
Дръжте лексиката точна и аргументът става по-кратък. Наборът е съвкупност от роли на едно ниво, шифърът е един компонент, а договореният резултат е единственото, което описва връзката, която наистина имате. Всичко останало в сравнението е украшение.