HTTPS Basic Auth a IPsec: co właściwie chroni każde z nich

Otwórz narzędzia deweloperskie, wczytaj wewnętrzną aplikację i zobacz, jak jedno żądanie przechodzi przez cztery punkty kontrolne, zanim strona się wyrenderuje. Najpierw nazwa jest rozwiązywana, potem otwiera się połączenie TCP, potem uzgadnianie TLS ustala, kim jest serwer, a dopiero potem aplikacja pyta, kim jesteś. Traktuj te zdarzenia osobno, bo każde zawodzi z innym dowodem i każde należy do innego zespołu. Większość zamieszania w incydentach bierze się z czytania 401 jako problemu tunelu albo problemu tunelu jako złego hasła.

Punkt kontrolny pierwszy: czy to serwer, z którym chciałeś rozmawiać

Uzgadnianie TLS odpowiada na to pytanie, zanim zostaną wysłane jakiekolwiek dane uwierzytelniające. Twój klient weryfikuje łańcuch certyfikatów wobec magazynu zaufania i sprawdza, czy nazwa w certyfikacie zgadza się z hostem, który wpisałeś. Jeśli to zawiedzie, przeglądarka pokazuje błąd certyfikatu i w ogóle nie wysyła nagłówka Authorization. Prośba o hasło nie jest więc dowodem, że serwer jest prawdziwy; jest dowodem, że aplikacja odpowiedziała.

Tu pojawia się pierwsza granica. TLS chroni połączenie do miejsca jego zakończenia. Jeśli load balancer kończy TLS i przekazuje do aplikacji zwykły HTTP, szyfrowany odcinek kończy się na balancerze, a dane uwierzytelniające są chronione tylko na pierwszym skoku.

Punkt kontrolny drugi: co naprawdę wędruje w wymianie 401

HTTP Basic przesyła identyfikator użytkownika i hasło w nagłówku, zakodowane w Base64, jak opisano w RFC 7617. Authorization: Basic dXNlcjpwYXNz to kształt; kodowanie jest odwracalne dla każdego, kto potrafi odczytać żądanie, więc cała tajność pochodzi z transportu pod spodem. curl -v pokazuje zarówno wyzwanie WWW-Authenticate: Basic, jak i nagłówek, który odsyłasz.

Ten nagłówek mówi aplikacji, kto pyta. Nie mówi sieci, kto może się połączyć, i sam niczego nie szyfruje. Aplikacja nadal musi sprawdzić dane uwierzytelniające w magazynie i zdecydować, co temu kontu wolno, a to jest autoryzacja i dzieje się po uwierzytelnieniu.

Gdzie w tej ścieżce leży tunel IPsec

Teraz wyjdź od przeglądarki na zewnątrz. Tunel IPsec między bramami chroni wybrany ruch między dwiema bramami bezpieczeństwa, a nie między twoim laptopem a procesem aplikacji. ESP w trybie tunelowym opakowuje oryginalny pakiet, bramy go szyfrują i uwierzytelniają, a wewnętrzne adresy przetrwają, dzięki czemu druga strona może skierować żądanie do aplikacji.

Selekcja to część, która ludzi przewraca. Tunele oparte na politykach używają selektorów ruchu, często wyrażonych jako listy kontroli dostępu, do decyzji, które pakiety wchodzą do tunelu. Tunele oparte na trasach używają zamiast tego interfejsu wirtualnego i tablicy routingu. W Linuksie ip xfrm policy pokazuje selektory, a ip xfrm state ustanowione asocjacje bezpieczeństwa; na urządzeniu firewallowym odpowiednikiem jest tablica SA tunelu plus tracer pakietów.

Konsekwencja jest warta powiedzenia wprost. Pakiet może siedzieć w całkowicie zdrowym tunelu i wciąż nieść żądanie HTTPS, które aplikacja odrzuca, a ważne dane uwierzytelniające mogą przyjść drogą bez żadnego tunelu, jeśli routing na to pozwala.

Czytaj awarię na warstwie, która ją zgłosiła

401 oznacza, że aplikacja nie przyjęła danych uwierzytelniających. 403 oznacza, że przyjęła tożsamość i odmówiła operacji. Błąd TLS oznacza, że klient nie przyjął serwera. Brak trasy lub niezgodność polityki oznacza, że pakiet nigdy nie dotarł do bramy po drugiej stronie. Cztery różne awarie, czterech różnych właścicieli, i żadnej z nich nie diagnozuje się, wpatrując się w formularz logowania.

Użyj dowodów, które produkuje każda warstwa: panel sieci przeglądarki dla statusu i nagłówków, openssl s_client -connect host:443 dla łańcucha certyfikatów, liczniki SA i logi bramy dla ruchu tunelowego oraz log aplikacji dla decyzji o koncie. Kiedy dwie warstwy zgłaszają błędy naraz, najpierw napraw niższą, bo martwy tunel łatwo maskuje błąd uwierzytelniania i odwrotnie.

Zmapuj jedną usługę od końca do końca

Napisz pięć wierszy dla usługi, którą diagnozujesz: jakie peery łączy tunel, jakie podsieci i porty dopuszczają selektory, gdzie kończy się TLS i jaką tożsamość potwierdza certyfikat, jakie konto aplikacji i rola są używane, oraz gdzie loguje każda warstwa. Trzymaj je na jednej stronie, bo sens mapy polega na pokazaniu, gdzie kończy się odpowiedzialność jednej warstwy, a zaczyna następnej.

Potem przetestuj jeden przypadek negatywny na warstwę. Użyj złego hasła i potwierdź, że dostajesz 401, a nie przekroczenie czasu. Połącz się z podsieci spoza selektorów i potwierdź, że pakiet nie idzie tunelem. Przedstaw certyfikat dla złej nazwy i potwierdź, że klient odmawia, zanim wyśle dane uwierzytelniające. Te trzy wyniki mówią o projekcie więcej niż jakikolwiek diagram pudełek.

Na koniec świadomie zdecyduj, jakiej ochrony potrzebuje każda relacja. Basic auth po TLS pasuje do małego wewnętrznego narzędzia za bramą; nie zastępuje autoryzacji na użytkownika ani ochrony ruchu poza punktem końcowym TLS. Tunel chroni drogę, certyfikat chroni skok, a 401 chroni konto, i tylko to ostatnie wie, kim jesteś.