Otvorite razvojne alate, učitajte internu aplikaciju i gledajte kako jedan zahtjev prolazi kroz četiri kontrolne točke prije nego se stranica prikaže. Prvo se razrješava ime, zatim se otvara TCP veza, zatim TLS rukovanje utvrđuje ko je poslužitelj i tek onda aplikacija pita ko ste vi. Tretirajte to kao odvojene događaje, jer svaki pada s različitim dokazima i svakim upravlja drugi tim. Većina zabune u incidentima dolazi od čitanja 401 kao problema s tunelom, ili problema s tunelom kao loše lozinke.

Kontrolna točka prva: je li to poslužitelj s kojim ste htjeli razgovarati

TLS rukovanje odgovara na to pitanje prije nego se pošalje bilo kakav akreditiv. Vaš klijent provjerava lanac certifikata prema spremištu povjerenja i provjerava da se ime u certifikatu podudara s hostom koji ste upisali. Ako to padne, preglednik prikaže pogrešku certifikata i uopće ne pošalje zaglavlje Authorization. Stoga upit za lozinku nije dokaz da je poslužitelj pravi; to je dokaz da je aplikacija odgovorila.

Ovdje se pojavljuje prva granica. TLS štiti vezu do njezine točke prekida. Ako balansir opterećenja prekida TLS i prosljeđuje obični HTTP aplikaciji, šifrirani segment završava na balansiru, a akreditivi su zaštićeni samo na tom prvom skoku.

Kontrolna točka druga: šta zapravo putuje u razmjeni 401

HTTP Basic provjera identiteta šalje korisnički identifikator i lozinku u zaglavlju, kodirane Base64, kako je opisano u RFC 7617. Authorization: Basic dXNlcjpwYXNz je oblik; kodiranje može poništiti svako ko može pročitati zahtjev, pa sva tajnost dolazi od transporta ispod. curl -v prikazuje i izazov WWW-Authenticate: Basic i zaglavlje koje vraćate.

To zaglavlje govori aplikaciji ko pita. Ne govori mreži ko se smije povezati i samo po sebi ne šifrira ništa. Aplikacija još mora provjeriti akreditiv prema spremištu i odlučiti šta taj račun smije raditi, što je autorizacija i događa se nakon provjere identiteta.

Gdje IPsec tunel sjedi na tom putu

Sada hodajte prema van od preglednika. IPsec tunel od pristupnika do pristupnika štiti odabrani promet između dva sigurnosna pristupnika, a ne između vašeg prijenosnika i procesa aplikacije. ESP u tunelskom načinu zamotava izvorni paket, pristupnici ga šifriraju i provjeravaju, a unutrašnje adrese ostaju kako bi daleka strana mogla usmjeriti zahtjev aplikaciji.

Odabir je dio na kojem se ljudi spotiču. Tuneli zasnovani na politikama koriste selektore prometa, često izražene kao popisi za kontrolu pristupa, da odluče koji paketi ulaze u tunel. Tuneli zasnovani na rutama umjesto toga koriste virtualno sučelje i tablicu usmjeravanja. Na Linuxu ip xfrm policy prikazuje selektore, a ip xfrm state uspostavljene sigurnosne asocijacije; na vatrozidnom uređaju ekvivalent je SA tablica tunela plus tragač paketa.

Posljedicu vrijedi reći jasno. Paket može sjediti unutar savršeno zdravog tunela i ipak nositi HTTPS zahtjev koji aplikacija odbija, a valjani akreditivi mogu stići putem bez ikakvog tunela ako usmjeravanje to dopušta.

Čitajte otkaz na sloju koji ga je prijavio

401 znači da aplikacija nije prihvatila akreditiv. 403 znači da je prihvatila identitet i odbila radnju. TLS pogreška znači da klijent nije prihvatio poslužitelj. Nema rute ili nepodudaranje politike znači da paket nikada nije stigao do dalekog pristupnika. Četiri različita otkaza, četiri različita vlasnika, i nijedan se ne dijagnosticira buljenjem u obrazac za prijavu.

Koristite dokaze koje svaki sloj proizvodi: mrežnu ploču preglednika za statuse i zaglavlja, openssl s_client -connect host:443 za lanac certifikata, SA brojače i zapise pristupnika za promet tunela, te zapis aplikacije za odluku o računu. Kada dva sloja prijave pogreške istovremeno, prvo popravite niži, jer mrtav tunel lako može prikriti neuspjeh provjere identiteta i obrnuto.

Mapirajte jednu uslugu od početka do kraja

Napišite pet redaka za uslugu koju rješavate: koje partnere tunel povezuje, koje podmreže i portove selektori dopuštaju, gdje TLS završava i koji identitet certifikat tvrdi, koji se korisnički račun i uloga koriste i gdje svaki sloj bilježi. Držite ih na jednoj stranici, jer svrha mape je pokazati gdje odgovornost jednog sloja prestaje i počinje sljedeći.

Zatim testirajte jedan negativni slučaj po sloju. Upotrijebite pogrešnu lozinku i potvrdite da dobivate 401, a ne istek vremena. Povežite se iz podmreže izvan selektora i potvrdite da paket ne ide kroz tunel. Predstavite certifikat za pogrešno ime i potvrdite da klijent odbija prije slanja akreditiva. Ta tri rezultata govore vam o dizajnu više od bilo kojeg dijagrama s kutijama.

Naposljetku, svjesno odlučite koja zaštita treba svakom odnosu. Osnovna provjera identiteta preko TLS-a razuman je izbor za mali interni alat iza pristupnika; nije zamjena za autorizaciju po korisniku ni za zaštitu prometa iza TLS krajnje točke. Tunel štiti put, certifikat štiti skok, a 401 štiti račun, i samo posljednje zna ko ste vi.

Povezani članci