HTTP põhiautentimine HTTPS-i kaudu versus IPsec: mida kumbki kaitseb

Avage arendaja tööriistad, laadige sisemine rakendus ja jälgige, kuidas üks päring läbib enne lehe kuvamist neli kontrollpunkti. Kõigepealt lahendatakse nimi, seejärel avaneb TCP-ühendus, seejärel teeb TLS käepigistus kindlaks, kes on server, ja alles siis küsib rakendus, kes te olete. Käsitlege neid eraldi sündmustena, sest igaüks ebaõnnestub erinevate tõenditega ja igaühte haldab erinev meeskond. Suurem osa juhtumite segadusest tuleb 401 lugemisest tunneliprobleemina või tunneliprobleemi lugemisest halva paroolina.

Esimene kontrollpunkt: kas see on server, kellega te tahtsite rääkida

TLS käepigistus vastab sellele küsimusele enne, kui ükski volitus saadetakse. Teie klient valideerib sertifikaadiahela usaldushoidla vastu ja kontrollib, et sertifikaadis olev nimi vastab teie sisestatud hostile. Kui see ebaõnnestub, näitab brauser sertifikaadiviga ega saada Authorization-päist üldse. Seega ei ole parooliküsimus tõend selle kohta, et server on ehtne; see on tõend selle kohta, et rakendus vastas.

Siin ilmub esimene piir. TLS kaitseb ühendust kuni oma lõpp-punktini. Kui koormusjaotur lõpetab TLS-i ja edastab rakendusele lihtsa HTTP, lõpeb krüptitud lõik koormusjaoturil ja volitused on kaitstud ainult sellel esimesel hüppel.

Teine kontrollpunkt: mis tegelikult 401 vahetuses liigub

HTTP põhiautentimine saadab kasutaja identifikaatori ja parooli päises, Base64-ga kodeerituna, nagu kirjeldatud dokumentatsioonis RFC 7617. Authorization: Basic dXNlcjpwYXNz on vorm; kodeeringu saab tagasi pöörata igaüks, kes päringut lugeda suudab, seega tuleb kogu salastatus selle all olevast transpordist. curl -v näitab nii WWW-Authenticate: Basic väljakutset kui ka päist, mille te tagasi saadate.

See päis ütleb rakendusele, kes küsib. See ei ütle võrgule, kes tohib ühenduda, ja ei krüpteeri iseenesest midagi. Rakendus peab ikkagi volitust hoidla vastu kontrollima ja otsustama, mida see konto tohib teha, mis on autoriseerimine ja toimub pärast autentimist.

Kus IPsec tunnel sellel teel asub

Nüüd liikuge brauserist väljapoole. Lüüsist lüüsini IPsec tunnel kaitseb valitud liiklust kahe turvalüüsi vahel, mitte teie sülearvuti ja rakendusprotsessi vahel. Tunnelirežiimis ESP mähkib algse paketi, lüüsid krüpteerivad ja autentivad selle ning siseaadressid jäävad alles, et kaugem pool saaks päringu rakendusele suunata.

Valik on see osa, mille peal inimesed komistavad. Poliitikal põhinevad tunnelid kasutavad liikluse selektoreid, mida väljendatakse sageli juurdepääsukontrolli loenditena, et otsustada, millised paketid tunnelisse sisenevad. Marsruudil põhinevad tunnelid kasutavad selle asemel virtuaalset liidest ja marsruutimistabelit. Linuxis näitab ip xfrm policy selektoreid ja ip xfrm state loodud turbeseoseid; tulemüüri seadmes on ekvivalent tunnel’i SA-tabel pluss paketijälgija.

Tagajärg tasub selgelt välja öelda. Pakett võib istuda täiesti terve tunnelis ja kanda siiski HTTPS-päringut, mille rakendus tagasi lükkab, ning kehtivad volitused võivad saabuda mööda teed, kus tunnelit üldse pole, kui marsruutimine seda lubab.

Lugege tõrget sellel kihil, mis sellest teatas

401 tähendab, et rakendus ei võtnud volitust vastu. 403 tähendab, et ta võttis identiteedi vastu ja keeldus toimingust. TLS-i viga tähendab, et klient ei võtnud serverit vastu. Marsruudi puudumine või poliitika mittevastavus tähendab, et pakett ei jõudnud kunagi kauge lüüsini. Neli erinevat tõrget, neli erinevat omanikku, ja ükski neist ei ole diagnoositav sisselogimisvormi jõllitades.

Kasutage tõendeid, mida iga kiht toodab: brauseri võrgupaneel oleku ja päiste jaoks, openssl s_client -connect host:443 sertifikaadiahela jaoks, lüüsi SA-loendurid ja logid tunneliliikluse jaoks ning rakenduse logi konto otsuse jaoks. Kui kaks kihti teatavad vigadest korraga, parandage kõigepealt madalam, sest surnud tunnel võib kergesti varjata autentimistõrget ja vastupidi.

Kaardistage üks teenus otsast otsani

Kirjutage viis rida teenuse kohta, mida te tõrkeotsingute teete: milliseid partnereid tunnel ühendab, milliseid alamvõrke ja porte selektorid lubavad, kus TLS lõpeb ja millist identiteeti sertifikaat kinnitab, millist rakendusekontot ja rolli kasutatakse, ja kus iga kiht logib. Hoidke need ühel lehel, sest kaardi mõte on näidata, kus ühe kihi vastutus lõpeb ja järgmine algab.

Seejärel testige iga kihi kohta üht negatiivset juhtumit. Kasutage valet parooli ja kinnitage, et saate 401, mitte ajalõpu. Ühenduge selektoritest väljapoole jäävast alamvõrgust ja kinnitage, et pakett ei lähe tunnelist läbi. Esitage vale nime jaoks sertifikaat ja kinnitage, et klient keeldub enne volituste saatmist. Need kolm tulemust ütlevad teile disaini kohta rohkem kui ükski kastiskeem.

Lõpuks otsustage teadlikult, millist kaitset iga suhe vajab. Põhiautentimine TLS-i kohal on mõistlik valik väikese sisemise tööriista jaoks lüüsi taga; see ei asenda kasutajapõhist autoriseerimist ega liikluse kaitset väljaspool TLS-i lõpp-punkti. Tunnel kaitseb teed, sertifikaat kaitseb hüpet ja 401 kaitseb kontot, ning ainult viimane teab, kes te olete.