HTTPS Basic аутентификација наспрам IPsec: шта сваки од њих штити

Отворите развојне алате, учитајте интерну апликацију и посматрајте како један захтев пролази кроз четири контролне тачке пре него што се страница прикаже. Прво се име разрешава, затим се отвара TCP веза, потом TLS руковање утврђује ко је сервер, и тек онда апликација пита ко сте ви. Третирајте то као одвојене догађаје, јер сваки од њих пада уз другачије доказе и сваки припада другом тиму. Највише забуне у инцидентима настаје када се 401 прочита као проблем тунела, или проблем тунела као лоша лозинка.

Контролна тачка један: да ли је ово сервер са којим сте хтели да разговарате

TLS руковање одговара на то питање пре него што се пошаље било који акредитив. Ваш клијент валидира ланац сертификата према складишту поверења и проверава да ли се име у сертификату поклапа са хостом који сте откуцали. Ако то не прође, прегледач приказује грешку сертификата и никада не шаље Authorization заглавље. Захтев за лозинком зато није доказ да је сервер прави; то је доказ да је апликација одговорила.

Овде се појављује прва граница. TLS штити везу до тачке на којој се прекида. Ако балансер оптерећења прекида TLS и прослеђује обичан HTTP апликацији, шифровани сегмент се завршава на балансеру, а акредитиви су заштићени само на том првом делу.

Контролна тачка два: шта заправо путује у размени 401

HTTP Basic аутентификација шаље идентификатор корисника и лозинку у заглављу, кодиране Base64 како је описано у RFC 7617. Authorization: Basic dXNlcjpwYXNz је облик; кодирање може да обрне свако ко може да прочита захтев, па сва тајност долази од транспорта испод. curl -v приказује и WWW-Authenticate: Basic изазов и заглавље које шаљете назад.

То заглавље говори апликацији ко пита. Не говори мрежи ко сме да се повеже, и само по себи ништа не шифрује. Апликација ипак мора да провери акредитив према складишту и одлучи шта тај налог сме да ради, а то је ауторизација и дешава се после аутентификације.

Где IPsec тунел стоји на том путу

Сада ходајте ка споља од прегледача. IPsec тунел између гејтвеја штити изабрани саобраћај између два безбедносна гејтвеја, не између вашег лаптопа и процеса апликације. ESP у тунелском режиму обавија оригинални пакет, гејтвејеви га шифрују и аутентификују, а унутрашње адресе остају сачуване како би друга страна могла да усмери захтев ка апликацији.

Избор је део који људе спотиче. Тунели засновани на политици користе селекторе саобраћаја, често изражене као листе контроле приступа, да одлуче који пакети улазе у тунел. Тунели засновани на рутама користе уместо тога виртуелни интерфејс и табелу рутирања. На Linux-у ip xfrm policy приказује селекторе а ip xfrm state приказује успостављене безбедносне асоцијације; на firewall уређају еквивалент је SA табела тунела плус праћење пакета.

Последицу вреди изговорити јасно. Пакет може да седи у савршено здравом тунелу и ипак носи HTTPS захтев који апликација одбија, а исправни акредитиви могу да стигну путем без тунела ако рутирање то дозвољава.

Прочитајте отказ на слоју који га је пријавио

401 значи да апликација није прихватила акредитив. 403 значи да је прихватила идентитет а одбила операцију. TLS грешка значи да клијент није прихватио сервер. Нема руте или неслагање политике значи да пакет никада није стигао до удаљеног гејтвеја. Четири различита отказа, четири различита власника, и ниједан се не дијагностикује бљењем у форму за пријаву.

Користите доказе које сваки слој производи: мрежни панел прегледача за статус и заглавља, openssl s_client -connect host:443 за ланац сертификата, SA бројаче и логове гејтвеја за саобраћај тунела, и лог апликације за одлуку о налогу. Када два слоја пријаве грешке истовремено, прво поправите доњи, јер мртав тунел лако може да маскира неуспех аутентификације и обрнуто.

Мапирајте једну услугу од почетка до краја

Напишите пет редова за услугу коју испитујете: које стране тунел повезује, које подмреже и портове селектори дозвољавају, где се TLS прекида и који идентитет сертификат тврди, који налог апликације и улога се користе, и где сваки слој логује. Држите их на једној страници, јер сврха мапе је да покаже где одговорност једног слоја престаје а следећи почиње.

Затим тестирајте један негативан случај по слоју. Употребите погрешну лозинку и потврдите да добијате 401, а не истек времена. Повежите се из подмреже ван селектора и потврдите да пакет није тунелован. Представите сертификат за погрешно име и потврдите да клијент одбија пре слања акредитива. Та три резултата говоре вам више о дизајну него било који дијаграм кутија.

На крају, свесно одлучите која заштита је потребна сваком односу. Basic аутентификација преко TLS-а разумно одговара малом интерном алату иза гејтвеја; није замена за ауторизацију по кориснику нити за заштиту саобраћаја изван TLS одредишта. Тунел штити пут, сертификат штити део, а 401 штити налог, и само последњи од њих зна ко сте ви.