OpenVPN username-as-common-name: зашто је ваша провера CN празна

Додајете скрипту client-connect која одбија сваку везу у којој се common_name разликује од username, и то изгледа као веза између сертификата и налога. На серверу који покреће username-as-common-name, то поређење је већ изгубило смисао док се скрипта покрене. Обе вредности су исти низ знакова, па тест пролази за сертификат издат сасвим другој особи.

Провера није погрешна зато што је скрипта лоше написана. Погрешна је зато што је вредност коју чита замењена раније у истој вези.

Шта поређење као да доказује

Аутентикација сертификатом и аутентикација лозинком су одвојени докази, а сервер може захтевати оба без захтева да припадају истој особи. Разлика је стварна: важећи сертификат уређаја плус било који важећи налог другачији је захтев од тог сертификата плус једног именованог налога. Скрипта која пореди common_name са username чита се као карика која недостаје између њих. Била би то, кад би common_name још значило оно што је сертификат рекао.

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

Шта username-as-common-name чини са именом

Са укљученим username-as-common-name, OpenVPN замењује уобичајено име сертификата аутентификованим корисничким именом након што се корисничко име и лозинка провере. Кука за проверу која се извршава током те провере још увек прима уобичајено име сертификата, јер се замена још није догодила. Све након тога, укључујући client-connect, види корисничко име. Зато каснији повратни позив прима један идентитет два пута и не може га упоредити са представљеним сертификатом.

Пратите једну илустративну везу: сертификат издат за bob-device, успешна пријава у именик као alice и укључена опција. Фаза провере још може да види два различита низа знакова. Фаза повезивања види alice и alice.

Тај пример показује зашто је поређење празно. Не показује да би веза иначе била прихваћена, јер провера сертификата и провера лозинке и даље раде саме.

Поставите везу тамо где оба идентитета још постоје

Правило мора да се спроводи у фази која види идентитет сертификата и налог истовремено, што у пракси значи куку за проверу корисничког имена и лозинке или тамо учитан додатак. Подржани додатак који већ обавља проверу лозинке обично је право место за додавање правила упаривања, јер би његова замена поређењем имена потпуно уклонила проверу лозинке.

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

Имајте на уму да опција мења и која се конфигурација по клијенту примењује, јер је client-config-dir везан за уобичајено име.

Тестирајте упаривање са два важећа акредитива

Почните са паром који ваша политика дозвољава и потврдите да се повезује. Затим представите исти важећи сертификат са другим, али иначе важећим налогом: тај покушај мора да пропадне, и мора да пропадне због правила упаривања, а не због погрешно унете лозинке. Погрешна лозинка доказује да провера лозинке ради и не говори ништа о правилу између сертификата и налога.

Проверите и путање без сертификата и са неважећим сертификатом и потврдите који идентитет сервер користи за подешавања по клијенту. Ако је једини начин да поређење ради искључивање username-as-common-name, прво процените цену те промене, јер она враћа тражење конфигурације сваког клијента на име сертификата.