Основна автентикација преку 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 го штити профилот, и само последниот знае кој сте вие.