Основна автентикация по 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 защитава акаунта и само последното знае кой сте вие.