saqib@seagate.com
Offshore XML/XHTML Development
Verziótörténet | ||
---|---|---|
Verzió: v4.1.1 | 2003.09.29 | Átdolgozta: sa |
Frissítések az SSL részben, az olvasói visszajelzésekre alapozva. | ||
Verzió: v4.1.0 | 2003.09.02 | Átdolgozta: sa |
Frissítések az SSL részben, az olvasói visszajelzésekre alapozva. | ||
Verzió: v4.0.2 | 2003.08.01 | Átdolgozta: sa |
Kissebb frissítések az Apache-ot beállító parancssorban. /dev/random hivatkozás az SSL részben. | ||
Verzió: v4.0.1 | 2003.07.27 | Átdolgozta: sa |
Az SSL fejezet további információval bővítve. | ||
Verzió: v4.0 | 2002.06.29 | Átdolgozta: sa |
Frissítve a HOGYAN Apache 2.0.-ra. A doksi forráskódja XML formátumú. | ||
Verzió: v3.4 | 2002.06.29 | Átdolgozta: sa |
Hozzáadva a "Hogyan generáljunk CSR-t" fejezet. | ||
Verzió: v3.3 | 2002.04.14 | Átdolgozta: sa |
Hozzáadva a "WebDAV szerver üzemeltetése" fejezet. |
Jelen dokumentum célja, hogy felépítsünk egy Apache + mySQL + PHP + WebDAV -alapú webes alkalmazásszervert, amely LDAP szerverek használatával végzi az azonosítást (authentication). A dokumentum felfedi a titkosított LDAP tranzakciókezelés egyes részleteit is.
![]() | Megjegyzés: |
---|---|
ha bármilyen problémával találkozol az Apache vagy valamely modul telepítésénél, lépj kapcsolatba velem a <saqib@seagate.com> e-mail címen. |
Ez a doksi eredetileg 2001-ben készült. Azóta számos frissítés és bővítés történt. Köszönet minden közreműködőnek a frissítésekért és javításokért.
Eme dokumentum XML kódja megtalálható a http://www.xml-dev.com:8080/cocoon/mount/docbook/Apache-WebDAV-LDAP-HOWTO.xml webhelyen.
A dokumentum utolsó változata a http://www.xml-dev.com:8080/cocoon/mount/docbook/Apache-WebDAV-LDAP-HOWTO.html honlapon található.
Ha szeretnél közreműködni a HOGYAN karbantartásában letöltheted az XML kódot a http://www.xml-dev.com:8080/cocoon/mount/docbook/Apache-WebDAV-LDAP-HOWTO.xml webhelyről, és elküldheted a frissített kódot a saqib@seagate.com e-mail címre A SZERZŐK LISTÁJÁBAN ÉS A VÁLTOZÁSOK TÖRTÉNETÉBEN A TE NEVEDDEL :). Ez megkönnyíti számomra a kapcsolatfelvételt mindazokkal akik frissítették/javították a doksit. Köszönöm.
Az Apache egy nyílt forráskódú http szerver modern operációs rendszerekre, amilyen a UNIX és a Windows NT. Http szolgáltatásokat nyújt a jelenlegi HTTP szabványoknak megfelelően.
Az Apache szabadon/ingyenesen letölthető a http://httpd.apache.org/ webhelyről.
A WebDAV egy Web enabled Distributed Authoring and Versioning, vagyis Web alapú Elosztott Szerzői és Változatnyilvántartó rendszer. Együttműködési környezetet biztosít azoknak a felhasználóknak, akik szerkesztik/karbantartják egy webszerver fájljait. Technikailag a DAV a http protokoll kiterjesztése.
Íme egy rövid leírás a DAV által biztosított bővítésekről:
Felülírási védelem: Zárolási és feloldási mechanizmus az "elveszett frissítés" probléma kiküszöbölésére. A DAV protokoll mind a megosztott, mind a kizárólagos zárolásokat támogatja.
Tulajdonságok: Meta-adatok (cím, tárgy, készítő, stb.)
Nevek karbantartása: Fájlok másolása, átnevezése, mozgatása és törlése.
Hozzáférés-szabályozás (Access Control; AC): A hozzáférés korlátozása bizonyos erőforrásokhoz. Jelenleg a DAV feltételezi az AC meglétét, és nem biztosít túl erős azonosítási mechanizmust.
Változatnyilvántartás: Dokumentumok revíziójának nyilvántartása. Még nem megvalósított.
A PHP (rekurzív betűszó "PHP: Hypertext Preprocessor"; "PHP: Hiperszöveg Előfeldolgozó") széleskörűen használt, nyíl forráskódú, általános célú szkript-nyelv, amely különösen Web-es fejlesztéseknél alkalmazható és beágyazható a HTML-be.
A PHP megtalálható a http://www.php.net webhelyen.
A MySQL a legnépszerűbb nyílt forráskódú SQL adatbázis-kezelő, a MySQL AB fejleszti, terjeszti és támogatja.
A mySQL adatbázismotor letölthető a http://www.mysql.com/ webhelyről.
A cél eléréséhez szükséges eszközök:
C Compiler, például GCC
Apache 2 Web szerver
LDAP Module az Apache-hoz
iPlanet LDAP lib fájlok
SSL motor
PHP
mySQL adatbázismotor
![]() | Megjegyzés: |
---|---|
Mindezen csomagok szabadon hozzáférhetők és letölthetők a Net-ről. |
A dokumentum feltételezi, hogy a következők már telepítve vannak a rendszereden.
gzip vagy gunzip - megtalálható a http://www.gnu.org webhelyen
gcc és GNU make - megtalálható a http://www.gnu.org webhelyen
A magyar fordítást Kilián Magdolna készítette (2003.03.28). A lektorálást Szijjártó László végezte el (2003.07.09). Utoljára Daczi László (dacas) frissítette (2003.10.06). A dokumentum legfrissebb változata megtalálható a Magyar Linux Dokumentációs Projekt honlapján.
Le kell töltenünk és fordítanunk néhány csomagot. Ez a HOGYAN elmagyarázza a fordítási folyamatot, de tudnunk kell forráskódból telepíteni.
Szükségünk van Solarisra/Linuxra és GNU CC fordítóra a gépen. A GNU gnzip és GNU tar szintén szükséges.
Az Apache egy HTTP szerver, Web-es alkalmazások kiszolgálására használjuk. Töltsd le az Apache 2.0.46 forráskódot a http://www.apache.org/dist/httpd/ webhelyről.
Töltsük le az OpenSSL csomagot a http://www.openssl.org/source/ webhelyről. A legutolsó verziót töltsük le. Az OpenSSL telepítést az SSL könyvtárak mod_ssl fordítására használjuk Apache-csal, valamint SSL bizonyítványok karbantartására a webszerveren. Töltsük le az OpenSSL forráskódot gzippelt fájlként a /tmp/downloads könyvtárba.
Töltsük le az iPlanet LDAP SDK csomagot a http://wwws.sun.com/software/download/products/3ec28dbd.html honlapról. Az iPlanet LDAP SDK csomagot fogjuk használni, mert ez tartalmazza az ldaps-hoz szükséges programkönyvtárakat (LDAP az SSL felett).
Az mod_auth_ldap csomagot az LDAP támogatás Apache-ba fordítására fogjuk használni. Töltsük le a http://www.muquit.com/muquit/software/mod_auth_ldap/mod_auth_ldap_apache2.html honlapról.
Töltsük le a soron következő mySQL csomagot a http://www.mysql.com/downloads/index.html honlapról.
Először ellenőrizzünk le néhány telepítési feltétel meglétét, majd kezdjük meg a telepítést.
Az alkalmazásszerver tervünk szerinti telepítéséhez szükségesek az SSL és LDAP programkönyvtárak. Az SSL motorra is szüksége van az Apach 2.x-nek, az SSL tanúsítványok kezeléséhez/használatához.
Jelentkezzünk be root felhasználóként, a su parancs használatával:
$ su - |
Hozzuk létre az /usr/local/iplanet-ldap-sdk.5 könyvtárat. Másoljuk az ldapcsdk5.08-Linux2.2_x86_glibc_PTH_OPT.OBJ.tar.gz fájlt a /tmp/downloads könyvtárból az /usr/local/iplanet-ldap-sdk.5 könyvtárba.
# mkdir /usr/local/iplanet-ldap-sdk.5 # cp /tmp/downloads/ldapcsdk5.08-Linux2.2_x86_glibc_PTH_OPT.OBJ.tar /usr/local/iplanet-ldap-sdk.5 # cd /usr/local/iplanet-ldap-sdk.5 # tar -xvf ldapcsdk5.08-Linux2.2_x86_glibc_PTH_OPT.OBJ.tar |
Most az összes szükséges iPlanet LDAP lib fájlnak a megfelelő könyvtárban kell lennie.
Ezután az OpenSSL motort kell telepítenünk.
Az OpenSSL az SSL/TLS protokoll nyílt forráskódú megvalósítása. Az OpenSSL szükséges az SSL tanúsítványok létrehozásához és kezeléséhez a webszerveren. A telepítés a lib fájlokhoz is szükséges, ezeket az SSL modul az Apache kiszolgálására használja.
Lépjünk be abba a könyvtárba, ahova az OpenSSL forráskódjának fájlait tetted.
# cd /tmp/download # gzip -d openssl.x.x.tar.gz # tar -xvf openssl.x.x.tar # cd openssl.x.x # make # make test # make install |
A make install lefutása után az openssl futtatható fájlai az /usr/local/ssl könyvtárban lesznek.
A mySQL telepítése elég egyszerű. A letöltött futtatható állományokat a megfelelő könyvtárba kell tenni.
Kezdetként hozzunk létre egy user:group csoportot a mysql démon számára, majd másoljuk be a fájlokat a megfelelő könyvtárakba.
# groupadd mysql # useradd -g mysql mysql # cd /usr/local # gunzip < /path/to/mysql-VERSION-OS.tar.gz | tar xvf - # ln -s full-path-to-mysql-VERSION-OS mysql |
Ezután futtassuk az install_db szkriptet, és állítsuk be a fájlok jogosultságait.
# cd mysql # scripts/mysql_install_db # chown -R mysql . |
Most indítsuk el a mySQL kiszolgálót a telepítés ellenőrzéséhez.
# bin/mysqld_safe --user=mysql & |
Ellenőrizzük a mySQL démon futását, a ps -ef parancs használatával. A következő kimenetnek kell megjelennie:
# ps -ef | grep mysql root 3237 1 0 May29 ? 00:00:00 /bin/sh bin/safe_mysqld mysql 3256 3237 0 May29 ? 00:06:58 /usr/local/mysql/bin/mysqld --defaults-extra-file=/usr/local/mysql/data/my.cnf --basedir=/usr/local/mysql --datadir=/usr/local/mysql/data --user=mysql --pid-file=/usr/local/mysql/data/downloa |
A MySQL kiszolgáló leállításához kövessük az alábbi útmutatást:
# cd /usr/local/mysql # ./bin/mysqladmin -u root -p shutdown |
A mySQL démon minden információt egy "Data Directory" nevű könyvtárban tárol. Ha követtük a fenti útmutatást, a Data Directory megtalálható az /usr/local/mysql/data könyvtár alatt.
A Data Directory helyének meghatározásához használjuk a mysqladmin segédprogramot, az alábbi módon:
# /usr/local/mysql/bin/mysqladmin variables -u root --password={your_password} | grep datadir |
Kezdjünk néhány FLAGS beállításával a fordító számára.
# export LDFLAGS="-L/usr/local/iplanet-ldap-sdk.5/lib/ -R/usr/local/iplanet-ldap-sdk.5/lib/:/usr/local/lib" # export CPPFLAGS="-I/usr/local/iplanet-ldap-sdk.5/include" |
Ezután csomagoljuk ki az Apache 2.0 forrásfájlait, és futtassuk a configure szkriptet.
# cd /tmp/download # gzip -d httpd-2.0.46.tar.gz # tar -xvf httpd-2.0.46.tar # cd httpd-2.0.46 #./configure --enable-so --with-ssl --enable-ssl --enable-rewrite --enable-dav |
Ezután adjuk ki a make parancsot
# make # make install |
Csomagoljuk ki a modauthldap_apache2.tar.gz fájlt.
cd /tmp/download # gzip -d modauthldap_apache2.tar.gz # tar -xvf modauthldap_apache2.tar # cd modauthldap_apache2 |
Most állítsuk be és telepítsük a mod_auth_ldap csomagot.
# ./configure --with-apxs=/usr/local/apache2/bin/apxs --with-ldap-dir=/usr/local/iplanet-ldap-sdk.5/ # make # make install |
Le kell töltenünk a cert7.db és key7.db adatbázisokat a http://www.xml-dev.com/xml/key3.db és http://www.xml-dev.com/xml/cert7.db webhelyről és el kell helyeznünk az /usr/local/apache2/sslcert/ könyvtárban.
Csomagoljuk ki a PHP forrásfájlokat.
gzip -d php-xxx.tar.gz tar -xvf php-xxx.tar |
Állítsuk be, majd futtassuk a make parancsot.
cd php-xxx ./configure --with-mysql --with-apxs=/usr/local/apache2/bin/apxs |
Fordítsuk le a forráskódot.
# make # make install |
Másoljuk a php.ini fájlt a megfelelő könyvtárba.
cp php.ini-dist /usr/local/lib/php.ini |
Ez egy könnyű rész. Ebben a fejezetben engedélyezni fogjuk a WebDAV szolgáltatást az Apache egy főkönyvtárában.
Ellenőrizzük a következő Apache direktívák meglétét az /usr/local/apache/conf/httpd.conf fájlban:
Addmodule mod_dav.c |
Amennyiben nincs benne, adjuk hozzá. Ez jelzi az Apache számára a DAV képesség meglétét. A direktívát mindenképp konténeren (container) kívül kell elhelyezni.
Ezt követően meg kell adnunk azt, hogy az Apache hol tárolja a DAVLockDB fájlt. Ez egy zárolási adatbázis a WebDAV-hoz, ezt írhatóvá kell tennünk a httpd processz számára.
A DAVLock fájlt én az /usr/local/apache/var könyvtárban tárolom. Én ezt a könyvtárat más célokra is használom. Adjuk hozzá a következő sort az /usr/local/apache/conf/httpd.conf fájlhoz, annak megadásához, hogy a DAVLockDB fájl az /usr/local/apache/var könyvtárban van:
DAVLockDB /usr/local/apache/var/DAVLock |
Az utasítást a tárolón kívül helyezzük el.
Mint fent említettem, egy könyvtárat kell létrehoznunk a DAVLockDB fájl számára, majd írhatóvá kell tennünk a webszerver folyamat számára. Általában a webszerver folyamat "nobody" felhasználói néven fut. Ellenőrizzük ezt a következő parancs használatával:
ps -ef | grep httpd |
# cd /usr/local/apache # mkdir var # chmod -R 755 var/ # chown -R nobody var/ # chgrp -R nobody var/ |
A DAV engedélyezése pofonegyszerű. Az Apache főkönyvtára alatti könyvtár DAV engedélyezéséhez, adjuk hozzá annak a bizonyos könyvtárnak a tárolójához a következő direktívát:
DAV On |
Ez engedélyezi a DAV-ot arra a könyvtárra és alkönyvtáraira.
A következő példa beállítás engedélyezi a DAV és LDAP azonosítást/hitelesítést az /usr/local/apache/htdocs/DAVtest könyvtárra. Rakjuk be az /usr/local/apache/conf/httpd.conf fájlba.
DavLockDB /tmp/DavLock <Directory "/usr/local/apache2/htdocs/DAVtest"> Options Indexes FollowSymLinks AllowOverride None order allow,deny allow from all AuthName "SMA Development server" AuthType Basic LDAP_Debug On #LDAP_Protocol_Version 3 #LDAP_Deref NEVER #LDAP_StartTLS On LDAP_Server you.ldap.server.com #LDAP_Port 389 # Ha az SSL aktív, meg kell határoznunk az LDAP SSL portot, ez általában 636 LDAP_Port 636 LDAP_CertDbDir /usr/local/apache2/sslcert Base_DN "o=SDS" UID_Attr uid DAV On #require valid-user require valid-user #require roomnumber "123 Center Building" #require filter "(&(telephonenumber=1234)(roomnumber=123))" #require group cn=rcs,ou=Groups </Directory> |
Mint egy korábbi részben említettem, minden DAV könyvtárnak írhatónak kell lennie a webszerver folyamat által. Ebben a példában feltételezzük, hogy a webszerver "nobody" név alatt fut. Ez az általános. A felhasználó megtekintéséhez (akinek neve alatt a webszerver fut) használjuk a
# ps -ef | grep httpd |
parancsot.
Hozzunk létre egy tesztkönyvtárat "DAVtest" néven az /usr/local/apache2/htdocs könyvtár alatt:
# mkdir /usr/local/apache/htdocs/DAVtest
Változtassuk meg a hozzáférési jogokat a könyvtárban, az legyen írható-olvasható a httpd folyamat számára. Feltételezve, hogy a httpd "nobody" felhasználónév alatt fut, használjuk a következő parancsokat:
# cd /usr/local/apache/htdocs # chmod -R 755 DAVtest/ # chown -R nobody DAVtest/ # chgrp -R nobody DAVtest/ |
Végül le kell futtatnunk az Apache-hoz mellékelt konfigurációs tesztrutint, a httpd.conf fájl szintaxisának ellenőrzéséhez:
# /usr/local/apache/bin/apachectl configtest |
Ha hibaüzenetet kapunk, akkor ellenőrizzük le, hogy minden utasítást helyesen követtünk-e. Ha nem tudod kitalálni a hiba okát, írj nekem (a hibaüzenetet is írd meg) a saqib@seagate.com e-mail címre.
Ha a konfiguráció tesztje sikeres, indítsuk el az Apache webszervert:
# /usr/local/apache/bin/apachectl restart
Most van egy WebDAV engedélyezett Apache szerverünk LDAP hitelesítéssel és SSL titkosítással.
Nagyon fontos, hogy a most telepített WebDAV teljesen összhangban legyen a WebDAV-2 protokollal. Ha nem teljesen kompatibilis, akkor a WebDAV alkalmazások kliens oldala nem fog rendesen működni.
A kompatibilitás teszteléséhez a Litmus nevű eszközt használjuk. A Litmus a WebDAV protokoll tesztelője, amely azt vizsgálja, hogy összhangban van-e egy szerver az RFC2518-ben leírt WebDAV protokollal.
Töltsük le a Litmus forráskódját a http://www.webdav.org/neon/litmus/ webhelyről, majd másoljuk be a /tmp/downloads könyvtárba.
Használjuk a gzip és tar programokat a kicsomagoláshoz:
# cd /tmp/downloads # gzip -d litmus-0.6.x.tar.gz # tar -xvf litmus-0.6.x.tar # cd litmus-0.6.x |
A Litmus fordítása és telepítése egyszerű:
# ./configure # make # make install |
A make install parancs a bináris fájlokat az /usr/local/bin, a súgó fájljait pedig az /usr/local/man könyvtárba teszi.
A most telepített WebDAV szerver teszteléséhez használjuk a
# /usr/local/bin/litmus http://you.dav.server/DAVtest userid passwd |
parancsot.
Ebben a részben megvitatjuk a különböző kezelési feladatokat - például LDAP belépés ellenőrzése, és hogyan dolgozunk Apache-on DAV módszerrel.
A legtöbb konfigurációs változást a DAV-hoz a httpd.conf fájl használatával tesszük. Ez a fájl az /usr/local/apache/conf/httpd.conf könyvtárban található.
A httpd.conf egy szöveges konfigurációs fájl, amelyet az Apache használ. Szerkesztéséhez bármely szövegszerkesztőt használhatjuk, én leginkább a vi-t szoktam. Készítsünk egy másolatot erről a fájlról, mielőtt megváltoztatjuk.
Miután a httpd.conf fájlban elvégeztük a változtatásokat, az Apache szervert újra kell indítani az /usr/local/apache/bin/apachectl restart paranccsal. Mielőtt újraindítanánk, teszteljük a httpd.conf érvényességét az /usr/local/apache/bin/apachectl configtest paranccsal.
Az előző részben, amikor létrehoztuk a DAVtest megosztást, az LDAP-ot hitelesítési célból használtuk. Azonban bárki, aki hitelesíti magát, az LDAP- ot használva a felhasználói azonosítójával/jelszavával, hozzáférhet ahhoz a mappához.
A require direktíva használatával a httpd.conf fájlban limitálhatjuk adott egyének vagy csoportok hozzáférését.
Ha megnézzük a DAVtest konfigurációt az előző részből :
<Directory /usr/local/apache/htdocs/DAVtest> Dav On #Options Indexes FollowSymLinks AllowOverride None order allow,deny allow from all AuthName "LDAP_userid_password_required" AuthType Basic <Limit GET PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK> Require valid-user </Limit> LDAP_Server ldap.server.com LDAP_Port 389 Base_DN "o=ROOT" UID_Attr uid </Directory> |
LDAP UID-t is használhatjuk a DAV mappa hozzáférésének korlátozására.
A require valid-user direktíva megváltoztatható require user 334455 445566 értékre.
Ez a 334455 és 445566 UID-vel rendelkező felhasználókra korlátozza a hozzáférést. Senki másnak nem lesz hozzáférése ehhez a mappához.
Lehetséges a DAV megosztások forrásainak szerkesztését bizonyos személyekre korlátozzuk, mindemellett bárki megnézheti ezeket az erőforrásokat (például fájlokat - dacas). Ezt könnyen tehetjük a <Limit> címke használatával a httpd.conf fájlban.
<Directory /usr/local/apache/htdocs/DAVtest> Dav On #Options Indexes FollowSymLinks AllowOverride None order allow,deny allow from all AuthName "LDAP_userid_password_required" AuthType Basic <Limit GET PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK> Require valid-user </Limit> LDAP_Server ldap.server.com LDAP_Port 389 Base_DN "o=ROOT" UID_Attr uid </Directory> |
A <limit> megváltoztatásával korlátozhatjuk adott személy írási jogát:
<Limit PUT POST DELETE PROPPATCH MKCOL COPY MOVE LOCK UNLOCK> Require 334455 </Limit> |
Alapvetően korlátozzuk a 334455 UID-vel rendelkező felhasználó PUT POST DELETE PROPPATH MKCOL COPY MOVE LOCK és az UNLOCK jogát. Mindenki más képes lesz használni a GET és PROPFIND módszert a forrásokon, de mást nem.
Manapság a fájlszerveren tárolt adatok biztonsága nagyon fontos. A kompromittált adatok több ezer dollárba is kerülhetnek egy társaságnak. Az utolsó részben LDAP hitelesítési modult fordítottunk az Apache-ba, hogy biztosítsuk a hitelesítési mechanizmust. Bár a HTTP forgalom nem igazán biztonságos, és minden adat tiszta szövegként jelenik meg - ez azt jelenti, hogy az LDAP hitelesítés (userid/passwd) ugyancsak tiszta szövegként megy át. Ez problémát okozhat. Bárki kutathat ezen userid/passwd párosok után és hozzáférhet a DAV állományhoz. Ennek megelőzéséhez titkosítanunk kell a HTTP forgalmat, valójában a HTTP+SSL vagy HTTPS segítségével. Bármi, ami átmegy a HTTPS-en, titkosított lesz, így az LDAP userid/passwd-ben nem kutakodhatnak. A HTTPS a 443-as porton fut. Az előző rész fordítási folyamatának eredményeként az Apache mindkét porton, a 80-ason (normál HTTP) és 443-ason (HTTPS) is fut. Ha csak a DAV-hoz használod majd a szervert, akkor erősen ajánlott bezárni a 80-as portot. A HOGYAN ezen részében néhány információt nyújtok az SSL-ről és annak üzemeltetéséről egy Apache HTTP szerveren.
Az SSL (Secure Socket Layer; Biztonsági Alréteg) egy protokoll réteg, amely a hálózati (Network layer) és az alkalmazási rétegek (Application layer) között van. Mint neve is sugallja, az SSL mindenféle forgalom titkosítására használható - LDAP, POP, IMAP és legfőképp HTTP.
Íme egy végletekig leegyszerűsített ábra az SSL-el kapcsolatban álló rétegekről.
+-------------------------------------------+ | LDAP | HTTP | POP | IMAP | +-------------------------------------------+ | SSL | +-------------------------------------------+ | Hálózati réteg (Network Layer) | +-------------------------------------------+ |
Háromféle titkosítási technológiát használnak az SSL-ben: "nyilvános-titkos kulcs" (Public-Private Key), "szimmetrikus kulcs" (Symmetric Key), és "üzenet ellenőrzés" (Message Digest).
"Nyilvános-titkos kulcs" titkosítás - SSL kapcsolat indítása: Ebben az algoritmusban a titkosítás és a visszafejtés nyilvános-titkos kulcspárral történik. A webszerveré a titkos kulcs, a nyilvános kulcsot pedig a tanúsítványban küldi el a kliensnek.
A kliens kéri a HTTPS-t használó Web szervertől a tartalmat.
A web szerver válaszol egy Digitális Tanúsítvánnyal (Digital Certificate), amiben benne van a szerver nyilvános kulcsa.
A kliens ellenőrzi, hogy lejárt-e a tanúsítvány.
Ezután a kliens ellenőrzi, hogy a tanúsítvány hatóság (Certificate Authority; továbbiakban CA), amely aláírta a tanúsítványt, megbízott hatóság-e a böngésző listáján. Ez a magyarázata annak, miért van szükségünk egy megbízott CA-tól kapott a tanúsítványra.
A kliens ellenőrzi, hogy a webszerver teljes domain neve (Fully Qualified Domain Name) megegyezik-e a tanúsítványon lévő közönséges névvel (Common Name).
Ha minden megfelelő, létrejön az SSL kapcsolat.
![]() | Megjegyzés: |
---|---|
Bármi, amit titkos kulccsal titkosítottak, kizárólag a nyilvános kulccsal fejthető vissza. Ennek megfelelően, bármilyen nyilvános kulccsal titkosított dolog, kizárólag a titkos kulccsal fejthető vissza. Elterjedt az a tévhit, miszerint kizárólag nyilvános kulccsal lehet titkosítani és titkos kulccsal visszafejteni. Ez nem így van. Bármelyik kulcs használható titkosításra és visszafejtésre egyaránt (ha annak párját használják visszafejtésre és titkosításra - dacas). Végül is, ha az egyik kulcsot használták titkosításra, a másikat kell használni a visszafejtésre stb. Egy üzenet nem titkosítható és visszafejthető kizárólag a nyilvános kulcs használatával. A titkos kulccsal történő titkosítás és a nyilvános kulccsal történő visszafejtés biztosíték a címzetteknek arról, hogy a küldeményt a küldő (a titkos kulcs tulajdonosa) adta fel (mivel a titkos kulcs használatához szükséges jelmondatot csak Ő ismeri - dacas). A nyilvános kulccsal történő titkosítás és titkos kulccsal visszafejtés biztosítja azt, hogy a küldeményt csak a meghatározott címzett (a titkos kulcs tulajdonosa) képes visszafejteni. |
Szimmetrikus titkosítás - az adatok tulajdonképpeni átvitele: Miután az SSL kapcsolat létrejött, szimmetrikus titkosítást használ az adatok titkosítására, kevesebb CPU ciklust felhasználva (tehát kevésbé erőforrás-igényes - a lektor). Szimmetrikus titkosításkor az adat ugyanazzal a kulccsal titkosítható és visszafejthető. A szimmetrikus titkosítás kulcsa a kapcsolat indításakor kerül átadásra, a nyilvános-titkos kulcspárral történő titkosítás alatt.
Üzenet ellenőrzés A szerver kivonatot készít az üzenetről valamilyen algoritmus szerint, mint például HMAC, SHA, MD5. Ezek alapján ellenőrzi az adatok sértetlenségét.
Titkosítási folyamat
Feladó Címzett titkos kulcsa nyilvános kulcsa ,-. ,-. ( ).......... ( ).......... `-' ''''|'|'|| `-' ''''''''|| | | | | | | .-----------. | | .-----------. | .-----------. | | V | |Titkosított| V |Titkosított| |Sima szöveg|-------->| szöveg |-------->| szöveg | | |1. lépés | 1 |2. lépés | 2 |\ `-----------' | `-----------' `----------' \ __ | | \ [_' | | 5. lépés\ | |3. lépés | __ --|-- | | _.--' | V | _..-'' / \ .----------. | _..-'' Címzett | SHA 1 | V .---------._..-'' | Üzenet |-------->|Digitális| | kivonat | 4. lépés| aláírás | _ `----------' `---------' _ (_) _____ ____ ____ ____ _ _ ____ _| |_ _ ___ ____ | ___ | _ \ / ___)/ ___) | | | _ (_ _) |/ _ \| _ \ | ____| | | ( (___| | | |_| | |_| || |_| | |_| | | | | |_____)_| |_|\____)_| \__ | __/ \__)_|\___/|_| |_| (____/|_| |
1. lépés: az eredeti "sima szöveg" titkosítása a feladó titkos kulcsának használatával, ennek eredménye a "titkosított szöveg 1". Ez biztosítja a feladó hitelességét.
2. lépés: a "titkosított szöveg 1" titkosítása a címzett nyilvános kulcsával, ennek eredménye a "titkosított szöveg 2". Ez biztosítja a címzett hitelességét (értsd: csak a címzett tudja visszafejteni a szöveget a saját titkos kulcsával).
3. lépés: az SHA1 üzenet kivonat (ellenőrző összeg - dacas) készítése a "sima szöveg" alapján.
4. lépés: SHA1 üzenet kivonat titkosítása a feladó titkos kulcsával, ennek eredménye a "sima szöveg" digitális aláírása. Ezt a digitális aláírást a címzett felhasználhatja az üzenet sértetlenségének és a feladó hitelességének ellenőrzésére.
5. lépés: a "digitális aláírás" és a "titkosított szöveg 2" elküldése a címzettnek.
Visszafejtési folyamat
Címzett Feladó titkos kulcsa nyilvános kulcsa ,-. ,-. ( ).......... ( ).......... `-' ''''''''|| `-' '''''''||| | | | | | | .-----------. | .-----------. | | .-----------. .----#1----. |Titkosított| V |Titkosított| V | | | | SHA 1 | | szöveg |------->| szöveg |--------->|Sima szöveg|------->| Üzenet | | 2 |1. lépés| 1 |2. lépés| | |3. lépés| kivonat | `-----------' `-----------' | `-----------' `----------' | || | ||5. lépés | || | || .---------. | .----------. |Digitális| V | SHA 1 | | aláírás |---------------------->| Üzenet | _ `---------' 4. lépés _ | kivonat | | | _ (_) `----#2----' __| |_____ ____ ____ _ _ ____ _| |_ _ ___ ____ / _ | ___ |/ ___)/ ___) | | | _ (_ _) |/ _ \| _ \ ( (_| | ____( (___| | | |_| | |_| || |_| | |_| | | | | \____|_____)\____)_| \__ | __/ \__)_|\___/|_| |_| (____/|_| |
1. lépés: a "titkosított szöveg 2" visszafejtése a címzett titkos kulcsának használatával, ennek eredménye a "titkosított szöveg 1".
2. lépés: a "titkosított szöveg 1" visszafejtése a feladó nyilvános kulcsának használatával, ennek eredménye a "sima szöveg".
3. lépés: SHA1 üzenet kivonat (ellenőrző összeg - dacas) elkészítése, az előző 2 lépés eredményeként kapott "sima szöveg" alapján.
4. lépés: a "digitális aláírás" visszafejtése a feladó nyilvános kulcsának használatával, ennek eredménye az "SHA1 üzenet kivonat".
5. lépés: az "SHA üzenet kivonat #1" és "SHA üzenet kivonat #2" összehasonlítása. Amennyiben a kettő egyezik, úgy az üzenet nem módosult az átvitel alatt, így az eredeti "sima szöveg" sértetlen.
Az Apache fordítása közben létrehoztunk egy teszt tanúsítványt. A mod-ssl csomagban lévő makefile programot használtuk az egyéni Tanúsítvány létrehozásához. Erre a
# make certificate TYPE=custom |
Ezt a tanúsítványt tesztelési célokra használhatjuk.
"Üzemi" használathoz szükségünk lesz egy tanúsítványra valamely Certificate Authority-tól (tanúsítvány hatóság) (ezentúl CA). A CA-k a tanúsítványt áruba bocsátók, akik egy megbízható CA listán vannak a felhasználó böngésző kliensében. Mint azt az algoritmus titkosítás részben említettem, ha a CA nincs a megbízott hatóságok listáján, a felhasználó figyelmeztető üzenetet kap, amikor megpróbál kapcsolódni egy biztosított/biztonságos helyhez.
Hasonlóan a teszt tanúsítványokhoz, ez is küld egy figyelmeztető üzenetet a felhasználó böngészőjének.
A CSR (TAK) vagy Certificate Signing Request-et (tanúsítvány aláírási kérelem) el kell küldeni egy megbízott CA-nak aláírásra. Ez a rész foglalkozik azzal, hogyan hozzunk létre CSR-t, és küldjük egy általunk kiválasztott CA-nak. Az # openssl req parancs használható erre, az alábbiak szerint:
# cd /usr/local/apache/conf/ # /usr/local/ssl/bin/openssl req -new -nodes -keyout private.key -out public.csr Generating a 1024 bit RSA private key ............++++++ ....++++++ writing new private key to 'private.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:California Locality Name (eg, city) []:San Jose Organization Name (eg, company) [Internet Widgits Pty Ltd]:Seagate Organizational Unit Name (eg, section) []:Global Client Server Common Name (eg, YOUR name) []:xml.seagate.com Email Address []:saqib@seagate.com Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []:badpassword An optional company name []: |
![]() | "PRNG not seeded" üzenet | |
---|---|---|
Ha nincs /dev/random könyvtár a rendszerünkön, "PRNG not seeded" hibaüzenetet kapunk. Ebben az esetben adjuk ki a következő parancsot:
A "some_file.ext" részt cseréljük ki egy rendszerünkön létező fájl nevére. Bármilyen fájlt megadhatunk. Az Openssl ezt fogja véletlen szám generáláshoz használni. |
Ezen a ponton pár kérdést tesz fel a szerver helyéről, hogy generálhassa a Certificate Signing Request-et.
Megjegyzés: A közönséges neved (Common Name) a teljes DNS neve (Fully Qualified DNS) a webszerverednek, például dav.server.com. Ha mást írunk oda, akkor NEM fog működni. Jegyezzük meg a használt jelszót, a jövőbeli használat érdekében.
Mihelyst befejeződött a folyamat, lesz egy private.key és egy public.csr fájlunk. Szükség lesz a public.csr fájlt bemutatnunk a CA-nak. Ekkor a public.key fájl még nem titkosított. A titkosításhoz használjuk az
# mv private.key private.key.unecrpyted # /usr/local/ssl/bin/openssl rsa -in private.key.unecrpyted -des3 -out private.key |
parancsokat.
Miután a CA feldolgozta a kérésünk, visszaküldenek egy kódolt tanúsítványt. A Digitális Tanúsítvány formátumát az X.509 v3 szabvány határozza meg. A következőkben látható egy tipikus, X509 v3 szabvány szerinti Digitális Tanúsítvány felépítése:
Certificate
Version
Serial Number
Algorithm ID
Issuer
Validity
Not Before
Not After
Subject
Subject Public Key Info
Public Key Algorithm
RSA Public Key
Extensions
Certificate Signature Algorithm
Certificate Signature
Egy X.509 Tanúsítvány ellenőrzésére használjuk a következő parancsot:
# openssl verify server.crt server.crt: OK |
Ahol a server.crt a Digitális Tanúsítványt tartalmazó fájl neve.
Egy Digitális Tanúsítvány tartalma megtekinthető a # openssl x509 parancs használatával, az alábbiak szerint:
# openssl x509 -text -in server.crt Certificate: Data: Version: 3 (0x2) Serial Number: 312312312 (0x0) Signature Algorithm: md5WithRSAEncryption Issuer: C=US, O=GTE Corporation, CN=GTE CyberTrust Root Validity Not Before: Feb 8 03:25:50 2000 GMT Not After : Feb 8 03:25:50 2001 GMT Subject: C=US, ST=New York, L=Pelham, O=xml-dev, OU=web, CN=www.xml-dev.com/Email=saqib@xml-dev.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): ............ ............ Exponent: 65537 (0x10001) Signature Algorithm: md5WithRSAEncryption ............ ............ |
Ezt kell elhelyeznünk a szerveren, és beállítanunk az Apache-ban ennek helyét.
Például a titkos kulcsot az /usr/local/apache2/conf/ssl.key/ könyvtárba, a tanúsítványt pedig az /usr/local/apache2/conf/ssl.crt/ könyvtárba.
Másoljuk le a tanúsítványt egy server.crt nevű fájlba, az /usr/local/apache2/conf/ssl.crt/ könyvtárba.
Az előző lépésben generált private.key fájlt helyezzük az /usr/local/apache2/conf/ssl.key/ könyvtárba
Ezután módosítsuk az /usr/local/apache2/conf/ssl.conf fájlt, hogy a megfelelő titkos kulcsra és tanúsítványra mutasson:
# Server Certificate: # Point SSLCertificateFile at a PEM encoded certificate. If # the certificate is encrypted, then you will be prompted for a # pass phrase. Note that a kill -HUP will prompt again. Keep # in mind that if you have both an RSA and a DSA certificate you # can configure both in parallel (to also allow the use of DSA # ciphers, etc.) SSLCertificateFile /usr/local/apache2/conf/ssl.crt/server.crt #SSLCertificateFile /usr/local/apache2/conf/ssl.crt/server-dsa.crt # Server Private Key: # If the key is not combined with the certificate, use this # directive to point at the key file. Keep in mind that if # you've both a RSA and a DSA private key you can configure # both in parallel (to also allow the use of DSA ciphers, etc.) SSLCertificateKeyFile /usr/local/apache2/conf/ssl.key/private.key #SSLCertificateKeyFile /usr/local/apache2/conf/ssl.key/server-dsa.key |
A webszerveren tárolt RSA titkos kulcs általában titkosított, ezért szükségünk van egy jelmondatra a használatához. Ezért kér jelmondatot, mikor az Apache-ot modssl-el indítjuk:
# apachectl startssl Apache/1.3.23 mod_ssl/2.8.6 (Pass Phrase Dialog) Some of your private key files are encrypted for security reasons. In order to read them you have to provide us with the pass phrases. Server your.server.dom:443 (RSA) Enter pass phrase: |
Az RSA titkos kulcs titkosítása nagyon fontos. Ha valaki megkaparintja a "titkosítatlan RSA titkos kulcsot", akkor könnyen eltulajdoníthatja a webszervert. Ha a kulcs titkosított, az illető nem tud semmit tenni a jelmondat nélkül, hacsak "nyers erővel" (brute force) fel nem töri. Használjunk erős (értsd: hosszú) jelmondatot erre a célra.
A kulcs titkosítása néha kellemetlenség forrása is lehet, mivel a webszerver minden indításakor kéri a jelmondatot. Különösen ha rc szkripteket használunk, a webszerver rendszerindításkor történő betöltéséhez. A jelmondat bekérése problémát okozhat, mivel megállítja a folyamatot, bemenetre vár.
Könnyen megszabadulhatunk a jelmondattól, ha visszafejtjük (decrypt) a kulcsot. Bizonyosodjunk meg arról, hogy senki se szerezheti meg a kulcsot. Vegyük figyelembe a biztonsági és védelmi ajánlásokat, mielőtt visszafejtjük a kulcsot a webszerveren.
A kulcs visszafejtésének módja:
Először készítsünk másolatot a titkosított kulcsról
# cp server.key server.key.cryp |
aztán írjuk újra a kulcsot titkosítással. Kérni fogja tőlünk az eredeti titkosított kulcs jelmondatát:
# /usr/local/ssl/bin/openssl rsa -in server.key.cryp -out server.key read RSA key Enter PEM pass phrase: writing RSA key |
Íme egy módja annak, miként biztosítsuk a visszafejtett titkos kulcsot. Így csak a root felhasználó olvashatja:
# chmod 400 server.key |
A digitális tanúsítvány (Digital Certificate) kibocsátója. Azon végfelhasználó (End-Entity) azonosságát is hitelesíti, amelynek birtokában van a digitális tanúsítvány.
A tanúsítvány aláírási kérelem (Certificate Signing Request; CSR) az, ami elküldésre kerül a tanúsítvány hatóságnak (Certifiate Authority; CA) bejegyzésre. Az aláírási kérelem tartalmazza a végfelhasználó (End-Entity) nyílvános kulcsát (Public Key), amelyre a digitális tanúsítványt kérelmezik.
A közönséges név (Common Name) a végfelhasználó (End-Entity) neve, például Saqib Ali. Ha a végfelhasználó egy webszerver, akkor ez a webszerver "teljesen képzett domain neve" (Fully Qualified Domain Name; FQDN).
Egy végfelhasználó (End-Entity) nyilvános kulcsa (Public Key) + a végfelhasználót (a nyilvános kulcs tulajdonosát) azonosító információ. Ez tanúsítja a végfelhasználó azonosságát. A tanúsítvány hatóság (Certificate Authority; CA) írja alá.
Egy digitális aláírás készítése az üzenet titkos kulccsal (Private Key) történő aláírásával történik. Ez biztosítja a feladó (Sender) (személy)azonosságát (Identity), és az adat sértetlenségét (Integrity of the Data).
A titkos kulcsot - az aszimmetrikus titkosítási rendszerben - a tulajdonosa (End-Entity) biztonságos helyen tartja. Titkosításra és visszafejtésre használható.
Az aszimmetrikus titkosítás nyilvános kulcsát széles körben terjesztik. Titkosításra és visszafejtésre használható.
Nyilvános kulcsos rendszer.
Az SSL egy biztonsági protokoll, amely hitelességet (digitális aláírás), megbízhatóságot (titkosítás) és adatsértetlenséget (üzenet ellenőrzés - MD5, SHA, stb.) biztosít
Ebben a rendszerben az üzenet ugyanazzal a kulccsal titkosítható és visszafejthető. (((n^2-n))/2) számú kulcsra van szüksége n felhasználónak, ha ezen módszer szerint akarnak titkosítani.