HTTPS Basic autentifikacija nasuprot IPsec: šta svaki od njih štiti

Otvorite razvojne alate, učitajte internu aplikaciju i posmatrajte kako jedan zahtev prolazi kroz četiri kontrolne tačke pre nego što se stranica prikaže. Prvo se ime razrešava, zatim se otvara TCP veza, potom TLS rukovanje utvrđuje ko je server, i tek onda aplikacija pita ko ste vi. Tretirajte to kao odvojene događaje, jer svaki od njih pada uz drugačije dokaze i svaki pripada drugom timu. Najviše zabune u incidentima nastaje kada se 401 pročita kao problem tunela, ili problem tunela kao loša lozinka.

Kontrolna tačka jedan: da li je ovo server sa kojim ste hteli da razgovarate

TLS rukovanje odgovara na to pitanje pre nego što se pošalje bilo koji akreditiv. Vaš klijent validira lanac sertifikata prema skladištu poverenja i proverava da li se ime u sertifikatu poklapa sa hostom koji ste otkucali. Ako to ne prođe, pregledač prikazuje grešku sertifikata i nikada ne šalje Authorization zaglavlje. Zahtev za lozinkom zato nije dokaz da je server pravi; to je dokaz da je aplikacija odgovorila.

Ovde se pojavljuje prva granica. TLS štiti vezu do tačke na kojoj se prekida. Ako balanser opterećenja prekida TLS i prosleđuje običan HTTP aplikaciji, šifrovani segment se završava na balanseru, a akreditivi su zaštićeni samo na tom prvom delu.

Kontrolna tačka dva: šta zapravo putuje u razmeni 401

HTTP Basic autentifikacija šalje identifikator korisnika i lozinku u zaglavlju, kodirane Base64 kako je opisano u RFC 7617. Authorization: Basic dXNlcjpwYXNz je oblik; kodiranje može da obrne svako ko može da pročita zahtev, pa sva tajnost dolazi od transporta ispod. curl -v prikazuje i WWW-Authenticate: Basic izazov i zaglavlje koje šaljete nazad.

To zaglavlje govori aplikaciji ko pita. Ne govori mreži ko sme da se poveže, i samo po sebi ništa ne šifruje. Aplikacija ipak mora da proveri akreditiv prema skladištu i odluči šta taj nalog sme da radi, a to je autorizacija i dešava se posle autentifikacije.

Gde IPsec tunel stoji na tom putu

Sada hodajte ka spolja od pregledača. IPsec tunel između gejtvejeva štiti izabrani saobraćaj između dva bezbednosna gejtveja, ne između vašeg laptopa i procesa aplikacije. ESP u tunelskom režimu obavija originalni paket, gejtvejevi ga šifruju i autentifikuju, a unutrašnje adrese ostaju sačuvane kako bi druga strana mogla da usmeri zahtev ka aplikaciji.

Izbor je deo koji ljude spotiče. Tuneli zasnovani na politici koriste selektore saobraćaja, često izražene kao liste kontrole pristupa, da odluče koji paketi ulaze u tunel. Tuneli zasnovani na rutama koriste umesto toga virtuelni interfejs i tabelu rutiranja. Na Linuxu ip xfrm policy prikazuje selektore a ip xfrm state prikazuje uspostavljene bezbednosne asocijacije; na firewall uređaju ekvivalent je SA tabela tunela plus praćenje paketa.

Posledicu vredi izgovoriti jasno. Paket može da sedi u savršeno zdravom tunelu i ipak nosi HTTPS zahtev koji aplikacija odbija, a ispravni akreditivi mogu da stignu putem bez tunela ako rutiranje to dozvoljava.

Pročitajte otkaz na sloju koji ga je prijavio

401 znači da aplikacija nije prihvatila akreditiv. 403 znači da je prihvatila identitet a odbila operaciju. TLS greška znači da klijent nije prihvatio server. Nema rute ili nesklad politike znači da paket nikada nije stigao do udaljenog gejtveja. Četiri različita otkaza, četiri različita vlasnika, i nijedan se ne dijagnostikuje buljenjem u formu za prijavu.

Koristite dokaze koje svaki sloj proizvodi: mrežni panel pregledača za status i zaglavlja, openssl s_client -connect host:443 za lanac sertifikata, SA brojače i logove gejtveja za saobraćaj tunela, i log aplikacije za odluku o nalogu. Kada dva sloja prijave greške istovremeno, prvo popravite donji, jer mrtav tunel lako može da maskira neuspeh autentifikacije i obrnuto.

Mapirajte jednu uslugu od početka do kraja

Napišite pet redova za uslugu koju ispitujete: koje strane tunel povezuje, koje podmreže i portove selektori dozvoljavaju, gde se TLS prekida i koji identitet sertifikat tvrdi, koji nalog aplikacije i uloga se koriste, i gde svaki sloj loguje. Držite ih na jednoj stranici, jer svrha mape je da pokaže gde odgovornost jednog sloja prestaje a sledeći počinje.

Zatim testirajte jedan negativan slučaj po sloju. Upotrebite pogrešnu lozinku i potvrdite da dobijate 401, a ne istek vremena. Povežite se iz podmreže van selektora i potvrdite da paket nije tunelovan. Predstavite sertifikat za pogrešno ime i potvrdite da klijent odbija pre slanja akreditiva. Ta tri rezultata govore vam više o dizajnu nego bilo koji dijagram kutija.

Na kraju, svesno odlučite koja zaštita je potrebna svakom odnosu. Basic autentifikacija preko TLS-a razumno odgovara malom internom alatu iza gejtveja; nije zamena za autorizaciju po korisniku niti za zaštitu saobraćaja izvan TLS odredišta. Tunel štiti put, sertifikat štiti deo, a 401 štiti nalog, i samo poslednji od njih zna ko ste vi.