Alapszintű hitelesítés HTTPS-en keresztül szemben az IPsec-kel: mit véd melyik

Nyissa meg a fejlesztői eszközöket, töltse be a belső alkalmazást, és figyelje meg, ahogy egy kérés négy ellenőrzőponton halad át, mielőtt az oldal megjelenik. Először a név oldódik fel, aztán megnyílik egy TCP-kapcsolat, aztán a TLS-kézfogás megállapítja, ki a kiszolgáló, és csak ezután kérdezi meg az alkalmazás, hogy Ön ki. Kezelje ezeket külön eseményekként, mert mindegyik más bizonyítékkal hibázik, és mindegyik más csapat felelőssége. Az incidensekben a legtöbb zavart az okozza, hogy a 401-et alagútproblémaként, vagy az alagútproblémát rossz jelszóként olvassák.

Első ellenőrzőpont: ez-e az a kiszolgáló, amellyel beszélni akart

A TLS-kézfogás még az előtt válaszol erre a kérdésre, hogy bármilyen hitelesítő adat elküldésre kerülne. Az ügyfél a tanúsítványláncot egy megbízhatósági tárolóval szemben ellenőrzi, és megnézi, hogy a tanúsítványban szereplő név megegyezik-e a beírt gazdagéppel. Ha ez meghiúsul, a böngésző tanúsítványhibát jelez, és az Authorization fejlécet egyáltalán nem küldi el. A jelszókérés tehát nem annak bizonyítéka, hogy a kiszolgáló valódi; annak bizonyítéka, hogy az alkalmazás válaszolt.

Itt jelenik meg az első határ. A TLS a kapcsolatot a végpontjáig védi. Ha egy terheléselosztó lezárja a TLS-t, és sima HTTP-t továbbít az alkalmazásnak, a titkosított szakasz a terheléselosztónál véget ér, és a hitelesítő adatok csak azon az első ugráson védettek.

Második ellenőrzőpont: mi utazik valójában egy 401-es csere során

A HTTP alapszintű hitelesítés a felhasználóazonosítót és a jelszót egy fejlécben küldi el, Base64-gyel kódolva, a RFC 7617 szabványban leírtak szerint. Authorization: Basic dXNlcjpwYXNz a forma; a kódolást bárki visszafordíthatja, aki olvasni tudja a kérést, tehát minden titok az alatta lévő átvitelből származik. curl -v megmutatja mind a WWW-Authenticate: Basic kihívást, mind a visszaküldött fejlécet.

Ez a fejléc megmondja az alkalmazásnak, ki kérdez. Nem mondja meg a hálózatnak, ki csatlakozhat, és önmagában semmit nem titkosít. Az alkalmazásnak továbbra is ellenőriznie kell a hitelesítő adatot egy tárolóval szemben, és el kell döntenie, mit tehet ez a fiók; ez az engedélyezés, és a hitelesítés után történik.

Hol helyezkedik el az IPsec-alagút ezen az úton

Most haladjon kifelé a böngészőtől. Az átjárók közötti IPsec-alagút a két biztonsági átjáró közötti kiválasztott forgalmat védi, nem a laptopja és az alkalmazásfolyamat között. Az alagút módú ESP becsomagolja az eredeti csomagot, az átjárók titkosítják és hitelesítik, a belső címek pedig megmaradnak, hogy a távoli oldal az alkalmazáshoz irányíthassa a kérést.

A kiválasztás az a rész, amelyen az emberek megbotlanak. A házirend-alapú alagutak forgalomválasztókat használnak, gyakran hozzáférés-vezérlési listákként kifejezve, hogy eldöntsék, mely csomagok lépnek be az alagútba. Az útvonal-alapú alagutak ehelyett virtuális interfészt és útválasztási táblázatot használnak. Linuxon a ip xfrm policy mutatja a választókat, a ip xfrm state pedig a létrejött biztonsági társításokat; tűzfalberendezésen a megfelelő az alagút SA-táblázata plusz egy csomagkövető.

A következményt érdemes nyíltan kimondani. Egy csomag ülhet egy teljesen egészséges alagútban, és mégis olyan HTTPS-kérést szállíthat, amelyet az alkalmazás elutasít, és érvényes hitelesítő adatok érkezhetnek alagút nélküli úton is, ha az útválasztás engedi.

A hibát azon a rétegen olvassa, amelyik jelentette

A 401 azt jelenti, hogy az alkalmazás nem fogadta el a hitelesítő adatot. A 403 azt jelenti, hogy elfogadta az identitást, és elutasította a műveletet. A TLS-hiba azt jelenti, hogy az ügyfél nem fogadta el a kiszolgálót. Az útvonal hiánya vagy a házirend-eltérés azt jelenti, hogy a csomag soha nem érte el a távoli átjárót. Négy különböző hiba, négy különböző felelős, és egyiket sem úgy diagnosztizálják, hogy a bejelentkezési űrlapot bámulják.

Használja a bizonyítékokat, amelyeket az egyes rétegek termelnek: a böngésző hálózati paneljét az állapotokhoz és fejlécekhez, a openssl s_client -connect host:443-öt a tanúsítványlánchoz, az átjáró SA-számlálóit és naplóit az alagútforgalomhoz, valamint az alkalmazás naplóját a fiók döntéséhez. Amikor két réteg egyszerre jelent hibákat, először az alsót javítsa, mert egy halott alagút könnyen elfedhet egy hitelesítési hibát, és fordítva.

Térképezzen fel egy szolgáltatást végponttól végpontig

Írjon öt sort arról a szolgáltatásról, amelyet vizsgál: mely partnereket köti össze az alagút, mely alhálózatokat és portokat engedélyeznek a választók, hol ér véget a TLS, és milyen identitást állít a tanúsítvány, melyik alkalmazásfiók és szerepkör használatos, és hol naplóz az egyes réteg. Tartsa őket egy oldalon, mert a térkép lényege megmutatni, hol ér véget az egyik réteg felelőssége, és hol kezdődik a következő.

Ezután teszteljen egy negatív esetet rétegenként. Használjon rossz jelszót, és ellenőrizze, hogy 401-et kap, nem időtúllépést. Csatlakozzon a választókon kívüli alhálózatról, és ellenőrizze, hogy a csomag nem halad át az alagúton. Mutasson be tanúsítványt a rossz névhez, és ellenőrizze, hogy az ügyfél megtagadja a hitelesítő adatok elküldése előtt. Ez a három eredmény többet mond a tervezésről, mint bármely dobozos ábra.

Végül tudatosan döntse el, milyen védelemre van szüksége az egyes kapcsolatoknak. A TLS feletti alapszintű hitelesítés ésszerű választás egy kis belső eszközhöz egy átjáró mögött; nem helyettesíti a felhasználónkénti engedélyezést vagy a TLS-végponton túli forgalom védelmét. Az alagút az utat védi, a tanúsítvány az ugrást, a 401 pedig a fiókot, és csak az utóbbi tudja, hogy ki Ön.