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, спачатку ацаніце кошт гэтай змены, бо яна пераносіць пошук канфігурацыі кожнага кліента назад на імя сертыфіката.