HTTPS арқылы негізгі аутентификация және IPsec: қайсысы нені қорғайды

Әзірлеуші құралдарын ашыңыз, ішкі қолданбаны жүктеңіз және бет көрсетілмес бұрын бір сұраныстың төрт бақылау нүктесінен өтуін бақылаңыз. Алдымен атау шешіледі, содан кейін TCP қосылымы ашылады, содан кейін TLS қол алысуы сервердің кім екенін анықтайды, тек содан кейін қолданба сіздің кім екеніңізді сұрайды. Оларды бөлек оқиғалар ретінде қарастырыңыз, өйткені әрқайсысы түрлі дәлелдермен сәтсіз аяқталады және әрқайсысы түрлі командаға тиесілі. Оқиғалардағы шатасудың көбі 401-ді туннель мәселесі ретінде, немесе туннель мәселесін нашар құпиясөз ретінде оқудан туындайды.

Бірінші бақылау нүктесі: бұл сіз сөйлескіңіз келген сервер ме

TLS қол алысуы бұл сұраққа кез келген тіркелгі деректері жіберілмес бұрын жауап береді. Клиентіңіз сертификаттар тізбегін сенім қоймасына қарсы тексереді және сертификаттағы атаудың сіз енгізген хостқа сәйкес келетінін тексереді. Егер бұл сәтсіз болса, браузер сертификат қатесін көрсетеді және Authorization тақырыбын мүлде жібермейді. Сондықтан құпиясөз сұрауы сервердің шынайы екенінің дәлелі емес; бұл қолданбаның жауап бергенінің дәлелі.

Мұнда бірінші шекара пайда болады. TLS қосылымды оның аяқталу нүктесіне дейін қорғайды. Егер жүктеме теңгерушісі TLS-ті аяқтап, қолданбаға қарапайым HTTP жіберсе, шифрланған сегмент теңгерушіде аяқталады, ал тіркелгі деректері тек сол бірінші секірісте қорғалады.

Екінші бақылау нүктесі: 401 алмасуында шын мәнінде не жүреді

HTTP негізгі аутентификациясы пайдаланушы идентификаторы мен құпиясөзді тақырыпқа салып жібереді, Base64-пен кодталған, сипатталғандай RFC 7617 құжатында. Authorization: Basic dXNlcjpwYXNz — бұл пішін; кодтауды сұранысты оқи алатын кез келген адам кері қайтара алады, сондықтан бүкіл құпиялылық астындағы тасымалдан келеді. curl -v әрі WWW-Authenticate: Basic шақыруын, әрі сіз қайтаратын тақырыпты көрсетеді.

Бұл тақырып қолданбаға кім сұрап отырғанын айтады. Ол желіге кім қосыла алатынын айтпайды және өзі ештеңені шифрламайды. Қолданба әлі де тіркелгі деректерін қоймаға қарсы тексеріп, бұл тіркелгінің не істей алатынын шешуі керек, бұл авторизация және аутентификациядан кейін болады.

IPsec туннелі сол жолда қайда тұр

Енді браузерден сыртқа қарай жүріңіз. Шлюзден шлюзге IPsec туннелі екі қауіпсіздік шлюзі арасындағы таңдалған трафикті қорғайды, ноутбугіңіз бен қолданба процесі арасында емес. Туннель режиміндегі ESP бастапқы пакетті орап алады, шлюздер оны шифрлап, аутентификациялайды, ал ішкі мекенжайлар сақталады, сондықтан алыс жақ сұранысты қолданбаға бағыттай алады.

Таңдау — адамдар сүрінетін бөлік. Саясатқа негізделген туннельдер қатынас таңдағыштарын пайдаланады, олар көбіне қатынас бақылау тізімдері ретінде өрнектеледі, қай пакеттердің туннельге кіретінін шешу үшін. Маршрутқа негізделген туннельдер оның орнына виртуалды интерфейс пен маршруттау кестесін пайдаланады. Linux-та ip xfrm policy таңдағыштарды, ал ip xfrm state орнатылған қауіпсіздік ассоциацияларын көрсетеді; желілік қалқан құрылғысында баламасы — туннельдің SA кестесі және пакет іздегіш.

Салдарды ашық айтуға тұрарлық. Пакет толығымен сау туннельдің ішінде отырып та, қолданба қабылдамайтын HTTPS сұранысын тасымалдай алады, ал жарамды тіркелгі деректері маршруттау рұқсат етсе, туннельсіз жолмен де келе алады.

Сәтсіздікті оны хабарлаған деңгейде оқыңыз

401 қолданбаның тіркелгі деректерін қабылдамағанын білдіреді. 403 оның жеке басын қабылдап, әрекеттен бас тартқанын білдіреді. TLS қатесі клиенттің серверді қабылдамағанын білдіреді. Маршруттың жоқтығы немесе саясаттың сәйкессіздігі пакеттің алыс шлюзге ешқашан жетпегенін білдіреді. Төрт түрлі сәтсіздік, төрт түрлі ие, және олардың ешқайсысы кіру нысанына қарау арқылы диагностикаланбайды.

Әр деңгей өндіретін дәлелдерді пайдаланыңыз: күй мен тақырыптар үшін браузердің желілік панелі, сертификаттар тізбегі үшін openssl s_client -connect host:443, туннель трафигі үшін шлюздің SA санағыштары мен журналдары, және тіркелгі шешімі үшін қолданба журналы. Екі деңгей бір уақытта қате хабарласа, алдымен төменгісін түзетіңіз, өйткені өлі туннель аутентификация сәтсіздігін оңай жасыра алады және керісінше.

Бір қызметті басынан аяғына дейін картаға түсіріңіз

Тексеріп жатқан қызмет үшін бес жол жазыңыз: туннель қандай серіктестерді қосады, таңдағыштар қандай ішкі желілер мен порттарға рұқсат береді, TLS қайда аяқталады және сертификат қандай жеке басты растайды, қандай қолданба тіркелгісі мен рөлі пайдаланылады, және әр деңгей қайда журнал жүргізеді. Оларды бір бетте ұстаңыз, өйткені картаның мақсаты — бір деңгейдің жауапкершілігі қайда аяқталып, келесісі қайда басталатынын көрсету.

Содан кейін әр деңгей үшін бір теріс жағдайды сынап көріңіз. Қате құпиясөзді пайдаланып, тайм-аут емес, 401 алатыныңызды растаңыз. Таңдағыштардан тыс ішкі желіден қосылып, пакеттің туннельден өтпейтінін растаңыз. Қате атау үшін сертификат ұсынып, клиенттің тіркелгі деректерін жібермес бұрын бас тартатынын растаңыз. Бұл үш нәтиже дизайн туралы кез келген қорап диаграммасынан көбірек айтады.

Соңында, әр қатынасқа қандай қорғаныс қажет екенін әдейі шешіңіз. TLS үстіндегі негізгі аутентификация шлюз артындағы шағын ішкі құрал үшін орынды таңдау; ол пайдаланушы бойынша авторизацияны немесе TLS соңғы нүктесінен тыс трафикті қорғауды алмастырмайды. Туннель жолды қорғайды, сертификат секірісті қорғайды, ал 401 тіркелгіні қорғайды, және тек соңғысы сіздің кім екеніңізді біледі.