Bazinis autentifikavimas per HTTPS prieš IPsec: ką kiekvienas saugo
Sekite vieną užklausą nuo naršyklės iki programos: TLS šuolis, 401 atsakymas ir tunelis saugo skirtingus ryšius ir nepavyksta su skirtingais įrodymais.
Atidarykite kūrėjo įrankius, įkelkite vidinę programą ir stebėkite, kaip viena užklausa pereina keturis kontrolės taškus prieš atvaizduojant puslapį. Pirmiausia išsprendžiamas vardas, tada atidaroma TCP jungtis, tada TLS rankos paspaudimas nustato, kas yra serveris, ir tik tada programa klausia, kas esate. Traktuokite tai kaip atskirus įvykius, nes kiekvienas jų nepavyksta su skirtingais įrodymais ir kiekvienas priklauso skirtingai komandai. Didžioji dalis painiavos incidentuose kyla iš 401 skaitymo kaip tunelio problemos, arba tunelio problemos kaip blogo slaptažodžio.
Pirmasis kontrolės taškas: ar tai serveris, su kuriuo norėjote kalbėtis
TLS rankos paspaudimas atsako į šį klausimą prieš išsiunčiant bet kokius prisijungimo duomenis. Jūsų klientas patikrina sertifikatų grandinę pagal patikimumo saugyklą ir patikrina, ar sertifikate esantis vardas atitinka įvestą mazgą. Jei tai nepavyksta, naršyklė rodo sertifikato klaidą ir visiškai nesiunčia Authorization antraštės. Taigi slaptažodžio užklausa nėra įrodymas, kad serveris tikras; tai įrodymas, kad programa atsakė.
Čia atsiranda pirmoji riba. TLS saugo ryšį iki jo pabaigos taško. Jei apkrovos balansuotojas užbaigia TLS ir perduoda paprastą HTTP programai, šifruotas segmentas baigiasi balansuotojuje, o prisijungimo duomenys saugomi tik tame pirmame šuolyje.
Antrasis kontrolės taškas: kas iš tikrųjų keliauja 401 apsikeitime
HTTP bazinis autentifikavimas siunčia vartotojo identifikatorių ir slaptažodį antraštėje, užkoduotus Base64, kaip aprašyta RFC 7617. Authorization: Basic dXNlcjpwYXNz yra forma; kodavimą gali atšaukti bet kas, kas gali perskaityti užklausą, todėl visas slaptumas ateina iš transporto po juo. curl -v rodo ir WWW-Authenticate: Basic iššūkį, ir antraštę, kurią grąžinate.
Ta antraštė pasako programai, kas klausia. Ji nepasako tinklui, kas gali prisijungti, ir pati nieko neužšifruoja. Programa vis tiek turi patikrinti prisijungimo duomenis pagal saugyklą ir nuspręsti, ką ši paskyra gali daryti, o tai yra autorizacija ir vyksta po autentifikavimo.
Kur tame kelyje yra IPsec tunelis
Dabar eikite į išorę nuo naršyklės. IPsec tunelis tarp tinklų sietuvų saugo pasirinktą srautą tarp dviejų saugumo sietuvų, o ne tarp jūsų nešiojamojo kompiuterio ir programos proceso. Tuneliniu režimu ESP apgaubia pradinį paketą, sietuvai jį užšifruoja ir autentifikuoja, o vidiniai adresai išlieka, kad tolimoji pusė galėtų nukreipti užklausą programai.
Pasirinkimas yra ta dalis, dėl kurios žmonės suklumpa. Politikos pagrindu veikiantys tuneliai naudoja srauto selektorius, dažnai išreikštus prieigos kontrolės sąrašais, kad nuspręstų, kurie paketai patenka į tunelį. Maršrutų pagrindu veikiantys tuneliai vietoj to naudoja virtualų sąsają ir maršrutizavimo lentelę. Linux sistemoje ip xfrm policy rodo selektorius, o ip xfrm state rodo nustatytus saugumo susiejimus; ugniasienės įrenginyje atitikmuo yra tunelio SA lentelė ir paketų stebėtojas.
Pasekmė verta pasakyti aiškiai. Paketas gali būti visiškai sveikame tunelyje ir vis tiek nešti HTTPS užklausą, kurią programa atmeta, o galiojantys prisijungimo duomenys gali atkeliauti keliu be jokio tunelio, jei maršrutizavimas tai leidžia.
Skaitykite gedimą tame sluoksnyje, kuris apie jį pranešė
401 reiškia, kad programa nepriėmė prisijungimo duomenų. 403 reiškia, kad ji priėmė tapatybę ir atsisakė operacijos. TLS klaida reiškia, kad klientas nepriėmė serverio. Nėra maršruto arba politikos neatitikimas reiškia, kad paketas niekada nepasiekė tolimosios sietuvos. Keturi skirtingi gedimai, keturi skirtingi savininkai, ir nė vienas jų nediagnozuojamas žiūrint į prisijungimo formą.
Naudokite įrodymus, kuriuos sukuria kiekvienas sluoksnis: naršyklės tinklo skydelį būsenoms ir antraštėms, openssl s_client -connect host:443 sertifikatų grandinei, sietuvos SA skaitiklius ir žurnalus tunelio srautui, o programos žurnalą paskyros sprendimui. Kai du sluoksniai vienu metu praneša apie klaidas, pirmiausia pataisykite žemesnįjį, nes miręs tunelis gali lengvai paslėpti autentifikavimo gedimą ir atvirkščiai.
Suskirstykite vieną paslaugą nuo pradžios iki pabaigos
Parašykite penkias eilutes paslaugai, kurią tiriate: kokius partnerius jungia tunelis, kokius potinklius ir prievadus leidžia selektoriai, kur baigiasi TLS ir kokią tapatybę tvirtina sertifikatas, kokia programos paskyra ir vaidmuo naudojami, ir kur kiekvienas sluoksnis registruoja. Laikykite juos viename puslapyje, nes žemėlapio tikslas yra parodyti, kur baigiasi vieno sluoksnio atsakomybė ir prasideda kitas.
Tada išbandykite vieną neigiamą atvejį kiekvienam sluoksniui. Naudokite neteisingą slaptažodį ir patvirtinkite, kad gaunate 401, o ne laiko limitą. Prisijunkite iš potinklio, esančio už selektorių, ir patvirtinkite, kad paketas neina per tunelį. Pateikite sertifikatą neteisingam vardui ir patvirtinkite, kad klientas atsisako prieš siųsdamas prisijungimo duomenis. Tie trys rezultatai pasako apie dizainą daugiau nei bet kokia dėžučių diagrama.
Galiausiai sąmoningai nuspręskite, kokios apsaugos reikia kiekvienam ryšiui. Bazinis autentifikavimas per TLS yra pagrįstas pasirinkimas mažam vidiniam įrankiui už sietuvos; jis nepakeičia autorizacijos kiekvienam vartotojui ar srauto apsaugos už TLS pabaigos taško. Tunelis saugo kelią, sertifikatas saugo šuolį, o 401 saugo paskyrą, ir tik paskutinis žino, kas esate.