Споделена DH група, свежи тайни: защо атаката става по-евтина

Параметрите на групата са публични по замисъл и именно тази публичност ги прави лесни за пренебрегване. При Diffie-Hellman над крайно поле модулът и генераторът се споделят, а частните показатели и получените сесийни ключове — не. Скъпата фаза на атака с решето по числово поле зависи от групата, а не от един обмен, затова една слаба група, използвана навсякъде, се превръща в споделена отговорност. Да наречем параметрите публични е точно и не по същество, защото цената, която се използва повторно, е цената за атака на тази група.

Публичната половина не е уязвимата половина и точно това е капанът

Обичайният половин аргумент казва, че параметрите са публикувани в стандарт, така че нападателят вече ги знае и скриването им нищо не би променило. И двете клаузи са верни и нито една не следва от другата. Групата по подразбиране, която се доставя, е публична, а частната група, която сте генерирали миналата седмица, също е видима за всеки, който завърши ръкостискането. Тайната никога не е била контролът; силата и проверката са.

Това, което се променя, е колко места споделят една и съща слабост. Една организация, която създава своя 2048-битова група, плаща за собствената си цена на атака, докато протоколно значение по подразбиране, избрано от милиони, амортизира една цена върху всички тях. В този смисъл необичайната група не е автоматично по-добра. Необичайна група, която е твърде малка, е просто по-малка споделена тайна с по-малко очи върху нея.

Проверката е също толкова важна, колкото размерът. Пир, който изпраща модул с малки множители или модул, който не е с формата, която протоколът очаква, може да изтече информация за частния показател, дори когато битовата дължина изглежда прилична. Библиотеките, които отхвърлят неправилните параметри на входа, вършат истинска работа, затова ръчно написаният разбор на параметри е лошо място за пестене на усилия.

Какво всъщност дава предварителното изчисление на нападателя

Решетото по числово поле има фаза, която зависи само от простото число, и резултатът му е многократно използваем срещу всеки обмен, който използва това просто число. Това е целият механизъм зад историческата тревога: скъпата част се плаща веднъж и пределната цена на всяка следваща сесия пада. Свежите показатели все още защитават всеки отделен обмен от пасивен наблюдател, стига групата да е достатъчно голяма, за да направи решетото невъзможно. Двете твърдения са съвместими и повечето спорове по тази тема идват от избирането на едното и изоставянето на другото.

Статията Logjam от 2015 г. демонстрира понижение до 512-битов Diffie-Hellman от експортен клас и оцени какво би струвало атакуването на по-големи, широко използвани групи със значителни ресурси. Демонстрацията беше конкретна, оценките бяха оценки и нито едно от двете не беше доказателство, че конкретна VPN сесия е дешифрирана.

Цитирайте статията заради механизма и демонстрираното понижение, а не като измерване на вашето внедряване. Старите статистики за това колко сървъра са споделяли група по подразбиране описват интернет от онази година, а не мрежа, която можете да прегледате днес. Полезното, което остава, е въпросът: договарят ли устройствата ви все още група, която е малка или слабо проверена?

Стандартизирано не значи слабо

RFC 7919 дефинира именувани групи над крайно поле, така че двете страни да се споразумеят за група по идентификатор и да прилагат последователна политика. Стандартизирането е предимство, защото премахва двусмислието при договарянето и позволява на реализацията да отказва неподдържани размери. Именуваната група е слаба само когато размерът й е под политиката, която твърдите, че следвате, а не защото се появява в документ. Същата логика важи и за групите на елиптичните криви, които имат различна структура и различни режими на отказ.

Дръжте конструкциите отделно, когато разсъждавате за тях. Изводът за Diffie-Hellman над крайно поле не казва нищо за X25519, а изводът за 1024-битова MODP група не казва нищо за 3072-битова. Политиката за сила е за всеки механизъм, всеки размер и всяка версия на протокола, затова фразата „силна криптография“ не е проверимо твърдение.

Автентикацията е другата половина и не замества. Силна група без проверка на пира оставя нападателя по средата, а валиден сертификат не може да спаси 768-битов обмен. Разглеждайте ги като две независими линии, после потвърдете, че и двете наистина са договорени.

Прочетете договорената група на реална връзка

Четете договорената група от устройството, а не от шаблона за конфигурация. Шаблоните описват намерение, а интересната стойност е тази, за която двете страни са се съгласили при последното ръкостискане. На крайна точка IPsec изходът за състоянието обикновено отпечатва избраното предложение, включително MODP групата.

Запишете този ред преди и след промяна на политиката и запазете и двата в записа за промяната. Сравнението е доказателството.

ipsec statusall | grep -Ei "proposal|ESP|IKE"
openssl dhparam -in /etc/vpn/dh3072.pem -check -noout

Ако след промяната състоянието все още показва старата група, връзката не е предоговорила и редакцията на конфигурацията не е доказала нищо. Рестартирайте пира или изчистете асоциацията за сигурност, после прочетете състоянието отново. Политика, прилагана само към нови връзки, ще остави дълготрайните тунели на старите параметри, докато те стоят.

Проверете групата и самоличността на пира поотделно

Отделете какво защитава групата от това кой е от другата страна. Записвайте метода за обмен на ключове, размера на групата и метода за автентикация като три полета, защото те се провалят независимо. Тунел, който е договорил 3072-битова група, но приема всеки сертификат, не е същият риск като такъв, който закрепва пир и използва 2048-битова група.

Запишете критериите за приемане преди началото на прегледа, така че резултатът да е сравнение, а не мнение. Минимален размер на групата за всяка версия на протокола, списък за разрешаване на именувани групи и задължителна проверка на пира са достатъчни, за да направят решението механично. Двусмислието в този списък превръща прегледа в спор, а споровете не се отстраняват. Тогава изходът е списък с крайни точки, които нарушават заявено правило.

ipsec statusall | grep -Ei "peer|auth|cert"
openssl s_client -connect vpn.acme.example:443 -brief -cipher 'DHE-RSA-AES256-GCM-SHA384'

Затворете цикъла, като прочетете отново договорените стойности след отстраняването. Съответстващ конфигурационен файл не е доказателство, че тунелът го е възприел. Изходът за състоянието и едно свежо ръкостискане са доказателството и събирането им отнема по-малко време от срещата дали са нужни.