OpenVPN username-as-common-name: зошто вашата CN проверка е празна
client-connect скрипта што го споредува common_name со username може да спореди име со самото себе. Поврзете го сертификатот со сметката пред да се изврши замената.
Додавате 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, го гледа корисничкото име. Затоа подоцнежниот повратен повик добива еден идентитет двапати и не може да го спореди со претставениот сертификат.
| Stage | What common_name holds |
|---|---|
| Username and password verification hook | The certificate common name, for example bob-device |
| After the replacement | The authenticated account, alice |
| client-connect callback | The account again, alice |
Следете една илустративна врска: сертификат издаден за bob-device, успешно најавување во директориумот како alice и овозможена опција. Фазата на проверка сѐ уште може да види две различни низи. Фазата на поврзување ги гледа alice и alice.
Овој пример покажува зошто споредбата е празна. Не покажува дека врската инаку би била прифатена, бидејќи проверката на сертификатот и проверката на лозинката сѐ уште работат самостојно.
Поставете ја врската таму каде двата идентитета сѐ уште постојат
Правилото мора да се спроведува во фаза што ги гледа идентитетот на сертификатот и сметката истовремено, што во пракса значи куката за проверка на корисничко име и лозинка или таму вчитан приклучок. Поддржан приклучок што веќе врши проверка на лозинка обично е вистинското место за додавање правило за спарување, бидејќи неговата замена со споредба на имиња целосно би ја отстранила проверката на лозинката.
Дефинирајте го мапирањето пред да пишувате код, бидејќи еднаквоста ретко е вистинската политика. Сертификатот често идентификува уред, а најавувањето идентификува лице, и еден уред може легитимно да служи на повеќе луѓе. Чувајте ја врската во форма чие издавање го контролирате, и одлучете што се случува при преименување, при повторно издавање и со имиња квалификувани со домен. Претворањето во мали букви или отстранувањето на доменски префикс без разбирање на директориумот може да спои две сметки што требало да останат одделни.
Запомнете дека опцијата менува и која конфигурација за секој клиент се применува, бидејќи client-config-dir е врзана со заедничкото име.
Тестирајте го спарувањето со два валидни акредитива
Започнете со парот што вашата политика го дозволува и потврдете дека се поврзува. Потоа претставете го истиот валиден сертификат со друга, но инаку валидна сметка: тој обид мора да не успее, и мора да не успее поради правилото за спарување, а не поради погрешно внесена лозинка. Погрешната лозинка докажува дека проверката на лозинка работи и не кажува ништо за правилото меѓу сертификатот и сметката.
Проверете ги и патеките без сертификат и со невалиден сертификат, и потврдете кој идентитет серверот го користи за поставките за секој клиент. Ако единствениот начин споредбата да работи е username-as-common-name да се исклучи, прво проценете ја цената на таа промена, бидејќи таа го враќа барањето конфигурација за секој клиент на името на сертификатот.