Зошто 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Во излезот читајте ги избраните алгоритми, а не понудената листа. Ако одговорот е послаб од она што политиката го предвидела, исправката припаѓа на конфигурацијата на предлогот на едната страна, а несовпаѓањето во современите имплементации обично се појавува како неуспешни преговори, а не како тивко намалување.
Потоа запомнете што комплетот не покрива. Рути, дозволи за апликации, евидентирање и задржување се одделни одлуки со сопствен преглед, а компатибилниот криптографски распоред не кажува ништо за нив. Разговорот за шифрата вреди, но одговара на потесно прашање од она што повеќето луѓе навистина го поставуваат.
Држете го речникот прецизен и аргументот станува пократок. Комплетот е множество улоги на ниво, шифрата е една компонента, а преговараниот резултат е единственото што ја опишува врската што навистина ја имате. Сè друго во споредбата е украс.