Baza identigo tra HTTPS kontraŭ IPsec: kion protektas ĉiu el ili

Malfermu la programilojn por ellaborantoj, ŝargu la internan aplikaĵon kaj observu unu peton trapasi kvar kontrolpunktojn antaŭ ol la paĝo montriĝas. Unue solviĝas la nomo, poste malfermiĝas TCP-konekto, poste TLS-manpremo difinas, kiu estas la servilo, kaj nur poste la aplikaĵo demandas, kiu vi estas. Traktu ilin kiel apartajn eventojn, ĉar ĉiu malsukcesas kun malsamaj pruvoj kaj ĉiun posedas malsama teamo. La plej multa konfuziĝo en incidentoj venas de legado de 401 kiel tunela problemo, aŭ de tunela problemo kiel malbona pasvorto.

Kontrolpunkto unu: ĉu temas pri la servilo, kun kiu vi volis paroli

La TLS-manpremo respondas tiun demandon antaŭ ol sendiĝas ajna legitimilo. Via kliento validigas la atestilan ĉenon kontraŭ fidata konservejo kaj kontrolas, ke la nomo en la atestilo kongruas kun la gastiganto, kiun vi tajpis. Se tio malsukcesas, la foliumilo montras atestilan eraron kaj tute ne sendas la kaplinion Authorization. Pasvorda peto do ne estas pruvo, ke la servilo estas aŭtentika; ĝi estas pruvo, ke la aplikaĵo respondis.

Ĉi tie aperas la unua limo. TLS protektas la konekton ĝis sia finpunkto. Se ŝarĝbalancilo finas TLS kaj plusendas simplan HTTP al la aplikaĵo, la ĉifrita segmento finiĝas ĉe la balancilo, kaj la legitimiloj estas protektitaj nur ĉe tiu unua salto.

Kontrolpunkto du: kio efektive vojaĝas en 401-interŝanĝo

HTTP-baza identigo sendas la uzantidentigilon kaj la pasvorton en kaplinio, kodigitaj per Base64, kiel priskribite en RFC 7617. Authorization: Basic dXNlcjpwYXNz estas la formo; la kodigon povas inversigi iu ajn, kiu povas legi la peton, do la tuta sekreteco venas de la transporto sube. curl -v montras kaj la defion WWW-Authenticate: Basic kaj la kaplinion, kiun vi resendas.

Tiu kaplinio diras al la aplikaĵo, kiu demandas. Ĝi ne diras al la reto, kiu rajtas konektiĝi, kaj ĝi mem nenion ĉifras. La aplikaĵo ankoraŭ devas kontroli la legitimilon kontraŭ konservejo kaj decidi, kion tiu konto rajtas fari, kio estas rajtigo kaj okazas post identigo.

Kie la IPsec-tunelo situas en tiu vojo

Nun iru eksteren de la foliumilo. IPsec-tunelo inter pordegoj protektas elektitan trafikon inter du sekurecpordegoj, ne inter via tekkomputilo kaj la aplikaĵa procezo. ESP en tunela reĝimo ĉirkaŭvolvas la originan paketon, la pordegoj ĝin ĉifras kaj aŭtentigas, kaj la internaj adresoj postvivas, por ke la malproksima flanko povu enkursigi la peton al la aplikaĵo.

La elekto estas la parto, pri kiu homoj faletas. Politikbazitaj tuneloj uzas trafikajn selektilojn, ofte esprimitajn kiel alirkontrolaj listoj, por decidi, kiuj paketoj eniras la tunelon. Itinbazitaj tuneloj anstataŭe uzas virtualan interfacon kaj la enkursigan tabelon. En Linux ip xfrm policy montras la selektilojn kaj ip xfrm state la starigitajn sekurecajn asociojn; en fajroŝirma aparato la ekvivalento estas la SA-tabelo de la tunelo plus paketa spurilo.

La sekvo indas diri klare. Paketo povas sidi en tute sana tunelo kaj tamen porti HTTPS-peton, kiun la aplikaĵo malakceptas, kaj validaj legitimiloj povas alveni laŭ vojo sen ia tunelo, se la enkursigado tion permesas.

Legu la malsukceson ĉe la tavolo, kiu raportis ĝin

401 signifas, ke la aplikaĵo ne akceptis la legitimilon. 403 signifas, ke ĝi akceptis la identecon kaj rifuzis la operacion. TLS-eraro signifas, ke la kliento ne akceptis la servilon. Neniu itinero aŭ politika maltrafo signifas, ke la paketo neniam atingis la malproksiman pordegon. Kvar malsamaj malsukcesoj, kvar malsamaj posedantoj, kaj neniu el ili diagnoziĝas per fiksrigardo al la ensaluta formularo.

Uzu la pruvojn, kiujn ĉiu tavolo produktas: la reta panelo de la foliumilo por statoj kaj kaplinioj, openssl s_client -connect host:443 por la atestila ĉeno, la SA-kalkuliloj kaj protokoloj de la pordego por tunela trafiko, kaj la protokolo de la aplikaĵo por la konto-decizo. Kiam du tavoloj raportas erarojn samtempe, ripari unue la pli malaltan, ĉar morta tunelo povas facile kaŝi identigan malsukceson kaj inverse.

Mapu unu servon de komenco ĝis fino

Skribu kvin liniojn por la servo, kiun vi priservas: kiujn partnerojn la tunelo kunligas, kiujn subretojn kaj pordojn la selektiloj permesas, kie TLS finiĝas kaj kiun identecon la atestilo asertas, kiun aplikaĵan konton kaj rolon oni uzas, kaj kie ĉiu tavolo protokolas. Tenu ilin sur unu paĝo, ĉar la celo de la mapo estas montri, kie la respondeco de unu tavolo finiĝas kaj la sekva komenciĝas.

Poste testu unu negativan kazon por tavolo. Uzu malĝustan pasvorton kaj konfirmu, ke vi ricevas 401, ne temporan limon. Konektiĝu el subreto ekster la selektiloj kaj konfirmu, ke la paketo ne iras tra la tunelo. Prezentu atestilon por malĝusta nomo kaj konfirmu, ke la kliento rifuzas antaŭ ol sendi legitimilojn. Tiuj tri rezultoj diras al vi pli pri la dezajno ol iu ajn diagramo de skatoloj.

Fine, konscie decidu, kiun protekton ĉiu rilato bezonas. Baza identigo super TLS estas racia elekto por malgranda interna ilo malantaŭ pordego; ĝi ne anstataŭas rajtigon por unuopa uzanto nek la protekton de trafiko preter la TLS-fina punkto. La tunelo protektas la vojon, la atestilo protektas la salton, kaj 401 protektas la konton, kaj nur la lasta scias, kiu vi estas.