Pamata autentifikācija HTTPS ietvaros pret IPsec: ko katra aizsargā

Atveriet izstrādātāja rīkus, ielādējiet iekšējo lietotni un vērojiet, kā viens pieprasījums pirms lapas attēlošanas iziet četrus kontroles punktus. Vispirms tiek atrisināts nosaukums, pēc tam atveras TCP savienojums, pēc tam TLS rokasspiediens nosaka, kas ir serveris, un tikai tad lietotne jautā, kas esat jūs. Uztveriet tos kā atsevišķus notikumus, jo katrs no tiem neizdodas ar atšķirīgiem pierādījumiem un katrs pieder citai komandai. Lielākā daļa apjukuma incidentos rodas no 401 lasīšanas kā tuneļa problēmas vai tuneļa problēmas kā slikta paroles vārda.

Pirmais kontroles punkts: vai tas ir serveris, ar kuru gribējāt runāt

TLS rokasspiediens atbild uz šo jautājumu pirms jebkādu autentifikācijas datu nosūtīšanas. Jūsu klients validē sertifikātu ķēdi pret uzticības krātuvi un pārbauda, vai sertifikātā esošais nosaukums atbilst ievadītajam resursdatoram. Ja tas neizdodas, pārlūks rāda sertifikāta kļūdu un vispār nesūta Authorization galveni. Tātad paroles pieprasījums nav pierādījums, ka serveris ir īsts; tas ir pierādījums, ka lietotne atbildēja.

Šeit parādās pirmā robeža. TLS aizsargā savienojumu līdz tā beigu punktam. Ja slodzes balansētājs pabeidz TLS un pārsūta vienkāršu HTTP lietotnei, šifrētais segments beidzas pie balansētāja, un autentifikācijas dati ir aizsargāti tikai tajā pirmajā lēcienā.

Otrais kontroles punkts: kas patiešām ceļo 401 apmaiņā

HTTP pamata autentifikācija sūta lietotāja identifikatoru un paroli galvenē, kodētu ar Base64, kā aprakstīts RFC 7617. Authorization: Basic dXNlcjpwYXNz ir forma; kodējumu var atgriezt jebkurš, kas spēj nolasīt pieprasījumu, tāpēc visa slepenība nāk no transporta zem tā. curl -v parāda gan WWW-Authenticate: Basic izaicinājumu, gan galveni, ko nosūtāt atpakaļ.

Šī galvene pasaka lietotnei, kas jautā. Tā nepasaka tīklam, kas drīkst savienoties, un tā pati neko nešifrē. Lietotnei joprojām ir jāpārbauda autentifikācijas dati pret krātuvi un jāizlemj, ko šis konts drīkst darīt, un tā ir autorizācija, kas notiek pēc autentifikācijas.

Kur šajā ceļā atrodas IPsec tunelis

Tagad ejiet uz āru no pārlūka. IPsec tunelis starp vārtejām aizsargā atlasīto satiksmi starp divām drošības vārtejām, nevis starp jūsu portatīvo datoru un lietotnes procesu. Tunela režīma ESP iesaiņo sākotnējo paketi, vārtejas to šifrē un autentificē, un iekšējās adreses saglabājas, lai tālā puse varētu maršrutēt pieprasījumu uz lietotni.

Atlase ir tā daļa, kur cilvēki paklūp. Uz politiku balstīti tuneļi izmanto satiksmes selektorus, bieži izteiktus kā piekļuves kontroles sarakstus, lai izlemtu, kuri paketes iekļūst tunelī. Uz maršrutu balstīti tuneļi tā vietā izmanto virtuālu saskarni un maršrutēšanas tabulu. Linux sistēmā ip xfrm policy parāda selektorus, bet ip xfrm state — izveidotās drošības asociācijas; ugunsmūra ierīcē ekvivalents ir tuneļa SA tabula plus pakešu izsekotājs.

Sekas ir vērts pateikt skaidri. Pakete var atrasties pilnīgi veselīgā tunelī un tomēr pārvadāt HTTPS pieprasījumu, ko lietotne noraida, un derīgi autentifikācijas dati var ierasties pa ceļu bez jebkāda tuneļa, ja maršrutēšana to atļauj.

Lasiet kļūmi tajā slānī, kas par to ziņoja

401 nozīmē, ka lietotne nepieņēma autentifikācijas datus. 403 nozīmē, ka tā pieņēma identitāti un atteicās no darbības. TLS kļūda nozīmē, ka klients nepieņēma serveri. Nav maršruta vai politikas neatbilstība nozīmē, ka pakete nekad nesasniedza tālo vārteju. Četras atšķirīgas kļūmes, četri atšķirīgi īpašnieki, un neviena no tām netiek diagnosticēta, skatoties uz pieteikšanās veidlapu.

Izmantojiet pierādījumus, ko rada katrs slānis: pārlūka tīkla paneli statusiem un galvenēm, openssl s_client -connect host:443 sertifikātu ķēdei, vārtejas SA skaitītājus un žurnālus tuneļa satiksmei, un lietotnes žurnālu konta lēmumam. Kad divi slāņi vienlaikus ziņo par kļūdām, vispirms labojiet zemāko, jo miris tunelis var viegli noslēpt autentifikācijas kļūmi un otrādi.

Kartējiet vienu pakalpojumu no sākuma līdz beigām

Uzrakstiet piecas rindas pakalpojumam, kuru pētāt: kurus partnerus tunelis savieno, kurus apakštīklus un portus pieļauj selektori, kur beidzas TLS un kādu identitāti apgalvo sertifikāts, kuru lietotnes kontu un lomu izmanto, un kur katrs slānis reģistrē žurnālu. Turiet tās vienā lapā, jo kartes mērķis ir parādīt, kur beidzas viena slāņa atbildība un sākas nākamais.

Pēc tam pārbaudiet vienu negatīvu gadījumu katram slānim. Izmantojiet nepareizu paroli un pārliecinieties, ka saņemat 401, nevis taimautu. Pieslēdzieties no apakštīkla ārpus selektoriem un pārliecinieties, ka pakete neiet caur tuneli. Uzrādiet sertifikātu nepareizajam nosaukumam un pārliecinieties, ka klients atsakās pirms autentifikācijas datu nosūtīšanas. Šie trīs rezultāti pastāsta par dizainu vairāk nekā jebkura kastīšu diagramma.

Visbeidzot, apzināti izlemiet, kāda aizsardzība nepieciešama katrai attiecībai. Pamata autentifikācija TLS virsū ir saprātīga izvēle mazam iekšējam rīkam aiz vārtejas; tā neaizstāj autorizāciju katram lietotājam vai satiksmes aizsardzību aiz TLS beigu punkta. Tunelis aizsargā ceļu, sertifikāts aizsargā lēcienu, un 401 aizsargā kontu, un tikai pēdējais zina, kas esat jūs.