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