Защо по-голям ключ на OpenVPN не премахва таймера за прегенериране

Изборът на AES-256 или на по-дълъг ключ не казва нищо за това колко дълго този ключ може да се използва. Силата на ключа описва алгоритъма; политиката за прегенериране решава кога сесията получава нов ключов материал. Едно внедряване може да избере най-силния наличен шифър и пак да сгреши с подновяването, защото двете решения се вземат на различни места. Смесването им води или до ненужна смяна на шифъра, или до сесия, която тихо надживява политиката си.

Прочетете настройките за прегенериране, преди да пипате шифъра, и четете и двете страни, когато го правите.

Силата на ключа и животът на ключа отговарят на различни въпроси

Шифърът и размерът на ключа определят колко скъпа би била атака срещу прихванат трафик. Интервалът за прегенериране определя колко трафик защитава един ключ и колко дълго компрометиран ключ остава полезен. Това са независими настройки и по-силният шифър не удължава безопасния живот на сесията. Повечето препоръки „използвайте AES-256“ мълчат за подновяването, защото то е въпрос на политика, а не избор на алгоритъм.

Запишете и двете в бележките за внедряване: какво защитава канала за данни и какво задейства подмяната на ключовете му.

Прегенерирането има три задействания и всяка страна може да ги отключи

OpenVPN 2.6 документира отделни задействания за предоговаряне по байтове, пакети и изминало време. Задействането по време е това, което повечето внедрявания оставят по подразбиране, което значи, че тихият тунел пак прегенерира по график. Всяка страна може да започне обмена, а страната, която не го е започнала, я следва. Затова смяната на таймера от една страна не определя поведението на сесията; ефективната стойност е на страната, която започне първа.

Задействанията по байтове и пакети имат значение при натоварване с висока пропускливост или дребни пакети, където политика само по време би позволила на един ключ да защитава много повече данни от предвиденото. Ако тези броячи останат изключени, кажете го умишлено в бележките, вместо да оставите подразбирането непроверено.

Прегенерирането разкрива процеса на удостоверяване

Предоговарянето е ново TLS ръкостискане, което значи, че пътят за удостоверяване се изпълнява отново. Внедряванията с еднократни кодове, хардуерни токени или RADIUS предизвикателство откриват това по трудния начин: първата връзка работи, а сесията умира час по-късно, когато второто ръкостискане поиска вече използван код. auth-gen-token съществува, за да запълни тази празнина, като позволи на сървъра да издаде краткотраен токен за предоговарянето, вместо да изисква нов интерактивен вход.

Третирайте това като проблем на процеса, който се решава с оператора, а не като доказателство, че подновяването трябва да се изключи.

Изпробвайте подновяването под натоварване, а не в едноминутна сесия

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

Не четете успешен голям трансфер като доказателство за криптографски праг. Той показва само, че пътят и броячите са издържали толкова трафик.

Документирайте и двата избора

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

Ако съвместимостта налага изключение, ограничете го до версия и крайна дата. Изключение, което надживее причината си, се превръща в политика, за която никой не помни, че е избирал.