OpenVPN без CA: како peer-fingerprint ги проверува партнерите
Отпечатокот прицврстува еден сертификат, а не заедничка тајна. Следете што покрива резимето, како секоја страна ја гради својата дозволена листа и што чини обновувањето.
Мало распоредување посегнува по отпечатоци затоа што сертификатниот орган изгледа како инфраструктура за која никој нема време. Инстинктот е разумен, но кратенката што луѓето ја избираат наместо тоа—копирање на една тајна на податочниот канал на двата краја—не е. peer-fingerprint поставеноста ја чува TLS структурата недопрена: секоја страна сѐ уште го држи својот приватен клуч и сертификат, и секоја страна сѐ уште ја проверува другата. Она што се менува е каде проверката е закотвена: од доверлив издавач до кратка листа на прицврстени резимеа. Бидејќи резимето го покрива целиот сертификат, а не име, обновувањето станува операција што навистина одзема време.
На што всушност се обврзува отпечатокот
Отпечатокот на сертификат е резиме на целиот DER-кодиран сертификат, а не на неговиот јавен клуч и не на името на неговиот субјект. Затоа два сертификати со идентични имиња и ист клуч, но различни датуми на важност имаат различни отпечатоци. Токму тоа го прави прицврстувањето прецизно, и токму тоа го прави обновувањето вознемирувачко. Прицврстувањето не може да значи доверба во клуч општо, затоа што именува еден артефакт во еден момент од неговиот живот. Секој може да го знае резимето, и самото знаење не докажува ништо.
openssl x509 -in server.crt -noout -fingerprint -sha256
openssl x509 -in client-07.crt -noout -fingerprint -sha256Поседувањето на соодветниот приватен клуч е она што докажува дека партнерот го држи тој сертификат, а резимето е начинот на кој другата страна одлучува дали воопшто го очекувала тој сертификат. Ова раздвојување е причината зошто овој дизајн не е стариот поредок со заедничка тајна: заедничкиот клуч автентикува секој што ги знае истите бајти, додека прицврстувањето автентикува еден сертификат. Друг уред добива свој запис наместо копија од истата тајна, што е мала разлика во датотеките и голема во опсегот на штетата.
Картата е взаемна, не симетрична
Секој крај има потреба од две работи: свој приватен клуч со сертификатот, и изјава за тоа кои партнерски сертификати ќе ги прифати. Кај клиентот таа изјава е резимето на серверскиот сертификат; кај серверот тоа е листата на регистрирани клиентски резимеа. Официјален пример за мало поставување за Community 2.6 ја покажува поставеноста со peer-fingerprint, и вреди да се прочита пред да го изберете овој модел на доверба за вистинско распоредување. Двете насоки не се една превртена листа, и тие не пропаѓаат во истиот момент.
| Verification direction | What is pinned | What never leaves that endpoint | How a wrong pin shows up |
|---|---|---|---|
| Client checks the server | One digest, for the server certificate | The server private key | The client aborts during the TLS handshake |
| Server checks the client | A digest per enrolled client | Each client private key | The server rejects the peer before a tunnel exists |
Додавањето уред ја уредува дозволената листа на серверот, без копирање на приватниот материјал на постоечки клиент и без преместување на серверскиот клуч никаде. Двете насоки исто така пропаѓаат независно, што е корисно при дијагноза: која страна го затвора ракувањето, таа страна го нема исполнито очекувањето. Ако клиентот го одбие серверот, резимето не се совпаѓа со претставениот сертификат. Ако серверот го одбие клиентот, резимето на тој клиент недостасува на листата, или клиентот претставува друг сертификат од регистрираниот.
Регистрација: како се придружува нов уред
Генерирајте го клучот и сертификатот на новиот уред таму каде што ќе живее приватниот клуч, потоа преместете го само јавниот артефакт кај страната што треба да го прицврсти. Пренесете го очекуваното резиме преку канал на кој веќе му верувате, и споредете го целиот сертификат наместо име што изгледа познато. Резиме копирано од истото непроверено преземање како сертификатот докажува само дека двете датотеки се совпаѓаат една со друга. Тоа е проверка на конзистентност, а не на идентитет, и тоа е најтивкиот начин на кој овој дизајн се ослабнува.
На серверот, додавањето на резимето е промена на конфигурацијата што поминува низ нормалниот менаџер и е следена од повторно поврзување. Потврдете дека новиот уред се поврзува и дека уред чие резиме е отстрането веќе не се поврзува. Тест што го покрива само позитивниот случај ја остава дозволената листа непроверена, и токму во таа состојба ќе бидете за шест месеци.
Обновувањето е скапиот момент
Секој сертификат истекува, и новиот сертификат има ново резиме дури и кога клучот и имињата остануваат исти. Под издавач, обновувањето е транспарентно за партнерите што му веруваат на тој издавач; под прицврстување, тоа е настан на регистрација за секој партнер што го прицврстува сертификатот.
Планирајте го редоследот пред датумот на истекување, а не по него. Дистрибуирајте го новото резиме до страните што го проверуваат, примените ја промената, и само тогаш заменете го сертификатот на крајот. Тој редослед не остава прозорец во кој двете страни не се согласуваат кој сертификат е тековен. Држете ја и самата листа под преглед, затоа што прицврстената листа собира записи за уреди повлечени пред месеци. Секој застарен запис е идентитет што сѐ уште се автентикува ако неговиот клуч преживее, па отстранувањето на еден е безбедносна акција, а не домашна работа.
Што не одлучува картата на доверба
Автентикацијата е еден слој, и прицврстената карта не кажува ништо за базенот на адреси, турканите рути, MTU на патеката или политиката на огнениот ѕид. Тие остануваат одделна конфигурација со одделни режими на откажување. Тунел што се автентикува и не пропушта никаков сообраќај е различно истражување од оној што никогаш не се крева.
Картата исто така не се скалира бесконечно, и PKI заснована на издавач е местото каде завршуваат поголемите распоредувања. Таа предност е за операциите, а не за криптографијата, затоа што додавањето и повлекувањето идентитети преку еден орган е поевтино отколку уредување на листа кај секој партнер како што расте флотата. Онаму каде клиентската имплементација не ја поддржува опцијата, одговорот е компатибилен модел на доверба што тој клиент го документира, или поддржана замена. Потиснувањето на предупредувањето за проверка не ја додава таа поддршка, и целата вредност на дизајнот е што проверката сѐ уште се случува.