Дневник на OpenVPN: шифър на контролния канал срещу шифър на канала за данни

Ред в дневника, който назовава DHE-RSA-AES256-SHA, не е обобщение на цялата връзка. Той принадлежи на TLS ръкостискането, което защитава контролния канал, а трафикът вътре в тунела може да е шифрован съвсем другояче. Да го представяте като шифър за данни на VPN е грешката, която трябва да се избегне.

Важни са два резултата и те отговарят на различни въпроси. Единият е договореният TLS комплект за контролния канал; другият е шифърът за данни на пакетите, които тунелът пренася.

Два резултата, два въпроса

Контролният канал пренася ръкостискането и управляващите съобщения между страните. Шифърът му се избира от TLS стека, затова името следва TLS конвенциите. Каналът за данни пренася потребителския трафик и се конфигурира от собственото договаряне на шифър на OpenVPN.

Решете на кой въпрос отговаряте, преди да прочетете който и да е от редовете. Дали тунелът е шифрован и дали ръкостискането е силно не е един и същ въпрос.

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

Декодирайте името на TLS комплекта в неговия контекст

В историческо име в стил OpenSSL като DHE-RSA-AES256-SHA всеки компонент описва различно решение. DHE е ефимерното Diffie-Hellman договаряне на ключове, RSA е методът за удостоверяване, AES256 е AES-256 в режим CBC за TLS записите, а SHA е MAC на записа, базиран на SHA-1.

Последният компонент не е отпечатък на сертификат и четенето му като такъв е честа грешка. Името също така само по себе си не посочва версията на протокола, защото TLS 1.3 използва напълно различна схема за именуване. TLS_AES_256_GCM_SHA384 следва по-новата форма, при която завършващият хеш е част от изграждането на комплекта, а не избор на MAC. Прилагайте четенето по компоненти само към по-стария стил на именуване.

Справочник за OpenSSL комплекти свързва тези имена с определенията им, ако някой компонент е непознат.

Прочетете резултата за канала за данни при пренасян трафик

За пренасяния трафик прочетете реда за канала за данни от същата сесия. Списъкът data-ciphers в конфигурацията е разрешено множество, а не доказателство, че е договорен конкретен алгоритъм. Дневникът записва избора; конфигурацията изброява менюто.

AEAD шифър като AES-GCM носи собствена проверка за цялост, така че отделен HMAC за канала за данни не е част от този път.

Директивата auth не надгражда TLS, сертификатите или шифъра за данни. Тя избира дигест за частите на протокола, които все още използват такъв, а при AEAD шифър за данни няма отделен HMAC за данни за конфигуриране.

Дръжте проверките за идентичност извън резултата на шифъра

Алгоритъмът за подпис на сертификата, проверката на веригата на доверие и проверката на името на партньора са още три свойства, за които името на шифъра не казва нищо. Изтекъл сертификат се проваля без значение колко е силен комплектът. Несъответстващо име на сървър се проваля по същия начин. Поправянето на настройка за дигест в профила не поправя нито едно от двете.

Дръжте тези проверки в бележките за преглед до резултата на шифъра, а не слети с него.

Запишете договорените резултати от текущата сесия

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

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