Базавая аўтэнтыфікацыя праз 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 абараняе ўліковы запіс, і толькі апошні ведае, хто вы.