Што прави однапред договорениот клуч во IPsec, OpenVPN и WireGuard

Зборовите однапред договорен клуч се појавуваат во документацијата на IPsec, OpenVPN и WireGuard, но означуваат три различни објекти. Едниот е тајна за автентикација, другиот штити контролен канал, а третиот додава материјал во ракување што веќе има идентитети. Ако ги сметате за заменливи, добивате врска што паѓа во фаза што никој не ја очекувал. Прочитајте што прави полето во тој протокол пред да копирате вредност во него.

Три протоколи, три значења

Секој протокол ја определува задачата на клучот во сопствената спецификација и тие задачи не се преклопуваат. Тајната за автентикација докажува дека две страни ја знаат истата вредност. Клучот на контролниот канал ги штити преговорите што следат. Додатокот на ракувањето го менува распоредот на клучевите, без да менува кои се страните.

Ниту една од тие улоги не автентицира човек, и токму тоа мешање чини најмногу време. Однапред договорениот клуч се доставува до уреди или порти пред размената, па секој сопственик изгледа исто за другата страна. Ова својство е предност за врска меѓу два рутера и ризик за услуга за далечински пристап со именувани вработени. Држете ги податоците за најава и криптографската тајна во одделни колони од документот што го опишува распоредувањето.

IPsec и OpenVPN го користат зборот поинаку

IKEv2 може да ја автентицира страната со однапред договорена тајна наместо со сертификати, а вредноста мора да се совпаѓа на двете страни. Бидејќи истата тајна обично се поставува за група страни, секој сопственик може да се претстави како останатите, а размената не добива никаква директна тајност од клучеви за идентитет што никогаш ги немала.

Опциите tls-auth и tls-crypt во OpenVPN прикачуваат статичен клуч на контролниот канал, додавајќи потпис HMAC или шифрирајќи ги самите преговори. Тој клуч не е корисничка лозинка и не го заменува клиентскиот сертификат. Разликувањето е важно при обнова, кога промената на лозинката го остава клучот на контролниот канал недопрен.

PSK во WireGuard додава, но не идентификува

Страните во WireGuard веќе имаат јавни и приватни клучеви Curve25519 и ракувањето ги автентицира тие идентитети. Изборниот однапред договорен клуч се вметнува во верижниот клуч и додава симетричен материјал врз размената на јавни клучеви.

Сам по себе не дава идентитет ниту корисничка сметка, затоа операторот не може да разликува двајца сопственици по нивниот PSK. Двете страни мора да ја носат истата вредност, инаку ракувањето паѓа без корисна порака за грешка. Затоа ротацијата треба да се планира за двете страни одеднаш, а не како уредување на една датотека.

Проверете распространување, ротација и отстранување

Распространувањето е слабата точка на секој проект што користи една тајна на многу места. Вредност вметната во прозорец за разговор, зачувана во складиште или повторно употребена меѓу средини собира копии што никој не може да ги наброи, и секоја копија тивко го шири опсегот на штета.

Текстот во Base64 не е шифрирање. Тајна чувана до јавен сертификат во истата папка и понатаму е тајна во отворен вид.

openssl rand -base64 32
sudo wg show wg0 preshared-keys
sudo grep -R -n 'psk' /etc/ipsec.d/ 2>/dev/null

Ротирајте по распоред и по секое сомневање за истекување, ажурирајќи ја секоја предвидена страна пред да ја повлечете старата вредност. Потоа тестирајте ја врската од двата краја, зашто клуч што не се совпаѓа паѓа при ракувањето и изгледа точно како проблем со огнен ѕид.

Запишете која тајна штити која фаза, за да не се помеша ресетирање на лозинка со обнова на криптографски клуч. Тој еден ред штеди час секогаш кога некој го проверува распоредувањето.