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 nagyon 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 "digitális aláírás" (Digital Signature).
"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 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ásigé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, majd 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 generálhatsz CSR-t és küldheted el egy általad 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 kapsz. Ebben az esetben add 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. A Solaris 9 rendszer részeként adnak /dev/random fájlt. Amennyiben Solaris rendszert használsz, elképzelhető, hogy telepítened kell a 112438 foltot a /dev/random fájl használatához. |
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 írsz oda, akkor NEM fog működni. Jegyezd 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ájlod. Szükséged 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áld 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ésed, 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áld 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 elhelyezned a szerveren, és beállítanod 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ásold 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 helyezd az /usr/local/apache2/conf/ssl.key/ könyvtárba
Ezután módosítsd 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éged van egy jelmondatra a használatához. Ezért kér jelmondatot, mikor az Apache-ot modssl-el indítod:
# 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álj erős (értsd: hosszú és értelmetlen) 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 megszabadulhatsz a jelmondattól, ha visszafejted (decrypt) a kulcsot. Bizonyosodj meg arról, hogy senki se szerezheti meg a kulcsot. Vedd figyelembe a biztonsági és védelmi ajánlásokat, mielőtt visszafejted a kulcsot a webszerveren.
A kulcs visszafejtésének módja:
Először készíts másolatot a titkosított kulcsról
# cp server.key server.key.cryp |
aztán írd újra a kulcsot titkosítással. Kérni fogja tőled 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íthatod a visszafejtett titkos kulcsot. Így csak a root felhasználó olvashatja:
# chmod 400 server.key |
Az Apache többfolyamatos modellt használ, amelyben NEM ugyanaz a munkafolyamat foglalkozik az összes kéréssel. Ennek eredményeként az SSL részfolyamat adatai (Session Information) elvesznek, mikor a kliens többszörös kéréssel fordul a szerverhez. A többszörös kapcsolódás nagy többletterhelést jelent a webszervernek és a kliensnek. Ennek elkerülésére az SSL részfolyamatok adatai egy munkafolyamatok közötti részfolyamat-tárban tárolódnak, ez lehetővé teszi a munkafolyamatok számára a kapcsolódási adatokhoz való hozzáférést. Az SSLSessionCache kapcsoló az /usr/local/apache2/conf/ssl.conf fájlban van, itt határozhatod meg az SSL részfolyamat-gyorstár helyét:
SSLSessionCache shmht:logs/ssl_scache(512000) #SSLSessionCache shmcb:logs/ssl_scache(512000) #SSLSessionCache dbm:logs/ssl_scache SSLSessionCacheTimeout 300 |
A dbm használata: a logs/ssl_scache DBF hash-fájlt készít gyorstárként a helyi lemezeden.
A shmht használata: a logs/ssl_scache(512000) a gyorstárat a megosztott memóriában hozza létre.
![]() | shmht vs shmcb |
---|---|
shmht: egy hash táblát használ az SSL kapcsolódási adatok gyorstárazására a megosztott memóriában. shmht: egy ciklikus buffert használ az SSL kapcsolódási adatok gyorstárazására a megosztott memóriában. |
![]() | Megjegyzés: |
---|---|
Nem minden platform/operációs rendszer támogatja hash tábla létrehozását a megosztott memóriában. Ekkor a "dbm:logs/ssl_scache"-t kell használnod helyette. |
Az SSLSessionCache megfelelő működésének ellenőrzésére az openssl segédprogramot használhatod a -reconnect kapcsolóval, mint azt a következőkben láthatod:
# openssl s_client -connect your.server.dom:443 -state -reconnect CONNECTED(00000003) ....... ....... Reused, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA SSL-Session: ..... Reused, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA SSL-Session: ..... Reused, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA SSL-Session: ..... Reused, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA SSL-Session: ..... Reused, TLSv1/SSLv3, Cipher is EDH-RSA-DES-CBC3-SHA SSL-Session: ..... |
A -reconnect kapcsoló kényszeríti az "s_client"-et arra, hogy ötször ugyanazzal a SSL munkafolyamat-azonosítóval (SSL session ID) kapcsolódjon a szerverhez. Ötször ugyanannak az SSL munkafolyamat-azonosítónak az újrahasználatát kell látnod, mint a fenti példában.
Előző | Tartalomjegyzék | Következő |
A WebDAV szerver üzemeltetése | HTTP/HTTPS teljesítménybeállító programok |