Základní ověřování přes HTTPS versus IPsec: co každá vrstva chrání

Otevřete vývojářské nástroje, načtěte interní aplikaci a sledujte, jak jeden požadavek projde čtyřmi kontrolními body, než se stránka vykreslí. Nejprve se přeloží jméno, potom se otevře TCP spojení, potom TLS handshake určí, kdo je server, a teprve pak se aplikace zeptá, kdo jste vy. Považujte to za oddělené události, protože každá selhává s jinými důkazy a každou vlastní jiný tým. Většina zmatení při incidentech pochází z toho, že se 401 čte jako problém tunelu nebo problém tunelu jako špatné heslo.

Kontrolní bod první: je to server, se kterým jste chtěli mluvit

TLS handshake odpovídá na tuto otázku dřív, než se odešle jakýkoli údaj. Váš klient ověří řetězec certifikátů proti úložišti důvěry a zkontroluje, že jméno v certifikátu odpovídá hostiteli, který jste zadali. Pokud to selže, prohlížeč zobrazí chybu certifikátu a hlavičku Authorization vůbec neodešle. Výzva k zadání hesla tedy není důkazem, že server je pravý; je důkazem, že aplikace odpověděla.

Tady se objevuje první hranice. TLS chrání spojení až do svého ukončovacího bodu. Pokud vyvažovač zátěže ukončí TLS a předá obyčejné HTTP aplikaci, šifrovaný segment končí na vyvažovači a přihlašovací údaje jsou chráněny jen na prvním skoku.

Kontrolní bod druhý: co skutečně cestuje při výměně 401

Základní ověřování HTTP posílá identifikátor uživatele a heslo v hlavičce, zakódované pomocí Base64, jak je popsáno v RFC 7617. Authorization: Basic dXNlcjpwYXNz je tvar; kódování může vrátit kdokoli, kdo požadavek přečte, takže veškeré utajení pochází z transportu pod ním. curl -v ukazuje jak výzvu WWW-Authenticate: Basic, tak hlavičku, kterou posíláte zpět.

Tato hlavička říká aplikaci, kdo se ptá. Neříká síti, kdo se smí připojit, a sama nic nešifruje. Aplikace stále musí ověřit údaj proti úložišti a rozhodnout, co tento účet smí dělat, což je autorizace a děje se po ověření.

Kde v této cestě sedí tunel IPsec

Teď jděte směrem ven od prohlížeče. Tunel IPsec mezi bránami chrání vybraný provoz mezi dvěma bezpečnostními bránami, ne mezi vaším notebookem a procesem aplikace. ESP v tunelovém režimu obalí původní paket, brány jej zašifrují a ověří a vnitřní adresy zůstanou, aby vzdálená strana mohla požadavek směrovat do aplikace.

Výběr je část, na které lidé klopýtnou. Tunely založené na zásadách používají selektory provozu, často vyjádřené jako seznamy pro řízení přístupu, k rozhodnutí, které pakety vstoupí do tunelu. Tunely založené na trasách místo toho používají virtuální rozhraní a směrovací tabulku. V Linuxu ip xfrm policy ukazuje selektory a ip xfrm state navázaná bezpečnostní přidružení; na zařízení firewallu je ekvivalentem tabulka SA tunelu plus sledovač paketů.

Důsledek stojí za to říct přímo. Paket může sedět v dokonale zdravém tunelu a přesto nést požadavek HTTPS, který aplikace odmítne, a platné údaje mohou dorazit cestou bez jakéhokoli tunelu, pokud to směrování dovolí.

Čtěte selhání na vrstvě, která ho nahlásila

401 znamená, že aplikace nepřijala údaj. 403 znamená, že přijala identitu a odmítla operaci. Chyba TLS znamená, že klient nepřijal server. Žádná trasa nebo nesoulad zásady znamená, že paket nikdy nedorazil ke vzdálené bráně. Čtyři různá selhání, čtyři různí vlastníci, a žádné z nich se nedá diagnostikovat zíráním na přihlašovací formulář.

Použijte důkazy, které každá vrstva produkuje: síťový panel prohlížeče pro stavy a hlavičky, openssl s_client -connect host:443 pro řetězec certifikátů, SA počítadla a protokoly brány pro provoz tunelu a protokol aplikace pro rozhodnutí o účtu. Když dvě vrstvy hlásí chyby současně, opravte nejdřív tu nižší, protože mrtvý tunel snadno zakryje selhání ověření a naopak.

Zmapujte jednu službu od začátku do konce

Napište pět řádků pro službu, kterou řešíte: které protějšky tunel propojuje, které podsítě a porty selektory povolují, kde končí TLS a jakou identitu certifikát tvrdí, který účet a role aplikace se používá a kde každá vrstva loguje. Udržte je na jedné stránce, protože smyslem mapy je ukázat, kde odpovědnost jedné vrstvy končí a začíná další.

Pak otestujte jeden negativní případ na vrstvu. Použijte špatné heslo a potvrďte, že dostanete 401, ne timeout. Připojte se z podsítě mimo selektory a potvrďte, že paket nejde tunelem. Předložte certifikát pro špatné jméno a potvrďte, že klient odmítne dřív, než odešle údaje. Tyto tři výsledky vám o návrhu řeknou víc než jakékoli schéma s rámečky.

Nakonec vědomě rozhodněte, jakou ochranu každý vztah potřebuje. Základní ověřování přes TLS je rozumná volba pro malý interní nástroj za branou; nenahrazuje autorizaci pro jednotlivé uživatele ani ochranu provozu za koncovým bodem TLS. Tunel chrání cestu, certifikát chrání skok a 401 chrání účet, a jen to poslední ví, kdo jste.