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.so Listen 443
SSLEngine on SSLCACertificateFile path/filename SSLCertificateFile path/filename SSLCertificateKeyFile path/filename SSLOptions +StdEnvVars +ExportCertData SSLVerifyClient require SSLVerifyDepth 10 Az "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.
Beállítások 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?
- a2enmod auth_digest
be kell állítani a modult - /etc/init.d/apache2 restart
érvényre kell juttatni a beállításokat - htpasswd -cs /var/www/private-basic/.passwd-basic useraron
a "c" létrehozza az állományt a "Basic" típushoz az "s" az alapértelmezett "MD5" helyett "SHA-1" lenyomatokat állít be "useraron:userpass" értékhez "useraron:{SHA}ZhF7w6sWXujTF+dghg2Ul9ZgAQw=" - htdigest -c /var/www/private-digest/.passwd-digest private-digest useraron
a "c" létrehozza az állományt a "Digest" típushoz "useraron:userpass" értékhez "useraron:private-digest:2c182809b74ec247071dbcde9c5f85db" - /etc/apache2/sites-enabled/default-ssl
az adott oldalra vonatkozó állományt kell módosítani - /etc/init.d/apache2 restart
érvényre kell juttatni a beállításokat A "default-ssl" állomány részlete így fest, ha - az alapértelmezett értékek mellé - bekerült valamelyik HTTP Access Authentication Scheme:

Ha mindennel kész vagyunk, akkor nézzük meg, hogy mi látszik a kommunikácóból a böngészőben (a felhasználó számára), illetve a forgalomfigyelő alkalmazásban!
HTTP Basic Access Authentication Scheme + SSL/TLS server/client authentication




HTTP Digest Access Authentication Scheme + SSL/TLS server/client authentication




Az IETF RFC 2617 szabványban leírt protokollok szabályai alapján írtam egy mintakódot (HTTP_Access_Authentication_Scheme.php), amivel tetszőleges "request" értékhez ki lehet számítani a "response" értékét különböző típusú HTTP Access Authentication Scheme esetén...
Kapcsolódó anyagok:
|