(nem hivatalos e-kormányzati témájú oldal)
| Mottó: Feels like I'm knockin' on heaven's door /Guns N' Roses: Knockin' on heaven's door/ | ||
| 2013. január 20. | ||
| HTTP/HTTPS Authentication | ||
| A napokban belebotlottam az IETF RFC 2617 szabványba miközben az egyik Apache2 web szerver felhasználó-hitelesítési beállításait módosítgattam. Hasznos olvasmány azoknak, akik szeretnék ismerni a hátterét a legegyszerűbben megvalósítható felhasználó-hitelesítési protokolloknak. Valóban ezek a legegyszerűbbek? Tény, hogy nem kell hozzájuk programozni, nem kell saját felhasználóhitelesítési- és session-kezelő függvényeket írni adatbáziskapcsolattal (bár, a felhasználói adatokat azért valahogy ki kell nyerni pl. egy megrendelési tranzakciónál), elég csak a web szervert konfigurálni. Egy ilyen "egyszerű, de jó megoldás" talán megér egy kis elemzést, hiszen sok esetben ez is jó lehet pl. az e-közigazgatásban (egy egyszerű név/jelszó párosnál legalábbis az SSL/TLS client authentication valamelyik HTTP hitelesítési protokollal kombinálva ezerszer jobb)... A protokollok közül a "HTTP Basic Access Authentication Scheme" azt hiszem, nem szorul bemutatásra, viszont a "HTTP Digest Access Authentication Scheme" már kevésbé számít ismertnek, noha beállítása ugyanolyan egyszerű. Mindkét protokollra még "rá lehet húzni" egy rejtjelezést megvalósító SSL/TLS réteget is, amelynél kétoldali, "server + client authentication" is beállítható. És valóban, ezek egyikéhez sem kell fejleszteni... De hogyan működnek ezek a protokollok? HTTP Basic Access Authentication Scheme A felhasználó böngészője "beköszön", amire a szerver HTTP 401-es hibával, illetve a "Basic" értékkel tér vissza HTTP üzenet fejlécében. A böngésző ezután a felhasználótól bekért nevet és jelszót egyszerűen base64 kódolva elküldi a szervernek, amire siker esetén már HTTP 200 jön válaszként. Vigyázni kell, mert ha nincs alatta egy SSL/TLS réteg, ami rejtjelezne, akkor a forgalmat figyelő támadó könnyen megszerezheti a jelszót... HTTP Digest Access Authentication Scheme A "Basic" esethez hasonlóan indul a kommunikáció, de a válaszban a "WWW-Authenticate" értéke "Digest", illetve a paraméterek között még érkezik egy "nonce" (véletlenszám, mint "challenge") és néhány egyéb adat is (pl. "algorithm"). A jelszóról, illetve egyéb adatokról több körben képződnek lenyomatok, amelyek elküldésre kerülnek a szervernek a felhasználónévvel együtt. Siker esetén HTTP 200 választ kap vissza a felhasználó böngészője. Itt már maga a jelszó nem megy át a csatornán, csak az abból képzett lenyomat, ami tulajdonképpen egy egyszeri jelszó ("nonce" alapján). Ezt is el lehet csípni, ha nincs SSL/TLS réteg, de ez az egyszeri jelszó már csak az adott "session" idejére engedhet hozzáférést... SSL/TLS server/client authentication A kétoldali, szerver és kliens oldali hitelesítésről már volt szó az "Alagút-effektus" és Robothadviselés - kicsit másképp bejegyzésemben. Ott már bemutatásra kerültek a szükséges beállítások, illetve hogy az SSL/TLS "handshake" révén miképp kerülnek hitelesítésre a felek és hogy jön létre a rejtjelezésre használt kulcs. Az ott leírtakat egy dologgal egészíteném ki: LoadModule ssl_module modules/mod_ssl.soAz "SSLOptions +StdEnvVars +ExportCertData" megadásával elérhetővé tehetők a környezet (pl. PHP, Java kód) számára az SSL/TLS "handshake" adatai, mint pl. a kliens által használt tanúsítvány ("SSL_CLIENT_CERT"). Ebből aztán tetszőleges adatot ki lehet nyerni, ami az authentikációhoz, naplózáshoz, elszámoláshoz szükséges lehet.
Programozni nem kell, de akkor miképp kell beállítani a web szervert (itt: Apache2), hogy a kívánt protokoll szerint működjön?
HTTP Basic Access Authentication Scheme + SSL/TLS server/client authentication
Kapcsolódó anyagok: | ||
| vissza | ||
info@ugyfelkapu.info
