Erinevus lehekülje "Apache ssl" redaktsioonide vahel
1. rida: | 1. rida: | ||
===Sissejuhatus=== | ===Sissejuhatus=== | ||
− | + | Alustame siiski eesmärgist: miks seda üldse hea teha on? | |
+ | |||
+ | Nagu öeldud on see seotud krüpteerimisega. Täpsemine, liiklus veebiserveri ja teine browseri vahel saab olema krüpteeritud. Antud juhul on selle tegemiseks vaja vähemalt veebiserveril omada public ja private keyd. Antud kontekstis nimetatakse serveri public key'd ka serveri sertifikaadiks. Niisiis, kui firefox külstab seda serverit, siis | ||
+ | |||
+ | - antakse talle serveri avalik võti (mille sisu pole põhimõtteliselt kellegile saladus) | ||
+ | - seejärel loob browser ilmselt midagi session key sarnast ning saadab servery public key'ga krüpreetirult session key serverile | ||
+ | - seda saadetist ei saa keegi peale vastava private key lahti võtta - st .ainult server | ||
+ | |||
+ | Tulemusena on mõlemad pooled kokku leppinud sümmeetrilise võtme millega edaspidi andmevahetust krüpteeritakse. | ||
+ | |||
+ | Võimalus mis on laialt levinud Kasutatada mitte mõne sertifitseerimiskeskuse | ||
+ | vaid iseenda poolt loodud ja sertifitseeritud viisio. | ||
+ | |||
+ | ===Praktika=== | ||
+ | |||
+ | Loome näiteks apache ssl ajutise self-signed sertifikaadi mis ei nõuaks parooli. | ||
Installitud peaks eelnevalt olema openssl | Installitud peaks eelnevalt olema openssl | ||
83. rida: | 98. rida: | ||
http://www.onlamp.com/pub/a/apache/2005/02/17/apacheckbk.html | http://www.onlamp.com/pub/a/apache/2005/02/17/apacheckbk.html | ||
+ | |||
+ | ===Ametlikud sertifikaadid=== | ||
+ | |||
+ | Teine lahendamist vajav asi on see, et tuleb luu olukord, kus: | ||
+ | |||
+ | - klient saab olla kindel, et server mida ta külastab on ikka see mis ta paistab olevat (nt. www.eyp.ee) | ||
+ | - server saab olla kindel, et klient on see kes ta ütleb end olevat | ||
+ | |||
+ | Osutub, et antud juhul on vaja kolmandat instanssi kes jagab välja 'pileteid'. Nii peab server omama autoriteetse instansi poolt väljastatud sertifikaati kus on sees instansi poolt signeeritud info selle kohta, et vot selle sertifikaadi esitaja on tõepoolest www.eyp.ee; sarnaselt on võimalik igal kliendil omandada sellelaadne sertifikaat kus instans on signeerinud, et jah, selle seritifikaadi esitaja on see ja see. | ||
+ | |||
+ | Reaalses elus tegutseb 'instansi'ina organisatsioon Verysign. Kuigi praktiliselt on nii, et krüpteeritud liiklust lubavad serverid ei hooli kas kliendil on või pole sertifikaati. Kliendi nö. isik tehakse parooli sisestamisega kindlaks. See on turvaline kuivõrd toimub juba krüpteeritud seansi sees. Aga klient peab hoolima küll, et server keda ta külastab oleks 'instansi' poolt sertifitseeritud. |
Redaktsioon: 22. detsember 2007, kell 14:28
Sisukord
Sissejuhatus
Alustame siiski eesmärgist: miks seda üldse hea teha on?
Nagu öeldud on see seotud krüpteerimisega. Täpsemine, liiklus veebiserveri ja teine browseri vahel saab olema krüpteeritud. Antud juhul on selle tegemiseks vaja vähemalt veebiserveril omada public ja private keyd. Antud kontekstis nimetatakse serveri public key'd ka serveri sertifikaadiks. Niisiis, kui firefox külstab seda serverit, siis
- antakse talle serveri avalik võti (mille sisu pole põhimõtteliselt kellegile saladus) - seejärel loob browser ilmselt midagi session key sarnast ning saadab servery public key'ga krüpreetirult session key serverile - seda saadetist ei saa keegi peale vastava private key lahti võtta - st .ainult server
Tulemusena on mõlemad pooled kokku leppinud sümmeetrilise võtme millega edaspidi andmevahetust krüpteeritakse.
Võimalus mis on laialt levinud Kasutatada mitte mõne sertifitseerimiskeskuse vaid iseenda poolt loodud ja sertifitseeritud viisio.
Praktika
Loome näiteks apache ssl ajutise self-signed sertifikaadi mis ei nõuaks parooli.
Installitud peaks eelnevalt olema openssl
Self-signed serfitikaadi loomine
openssl genrsa -des3 -out server.key 1024 openssl req -new -key server.key -out server.csr openssl x509 -req -days 300 -in server.csr -signkey server.key -out server.crt openssl rsa -in server.key -out server.key
chmod 0400 server.key chmod 0400 server.crt
Apache seadistus
Apache peab olema eelnevalt kompileeritud SSL toega. Näites on kasutatud versiooni apache 2.x versioonil 1.3 võib olla erinevusi.
FreeBSD
Lisame FreeBSD's faili /etc/rc.conf rea
apache2ssl_enable="YES"
Käivitame apache ssl toega
apachectl sslstart
Kontrollime käsuga sockstat, kas kuulab?
# sockstat | grep 443 www httpd 20720 4 tcp46 *:443 *:* www httpd 20709 4 tcp46 *:443 *:* www httpd 20020 4 tcp46 *:443 *:* www httpd 20019 4 tcp46 *:443 *:*
kuulab :]
Gentoo
Failis /etc/conf.d/apache2
Lisame APACHE2_OPTS= reale lisaks -D SSL
näiteks nii
APACHE2_OPTS="-D PHP5 -D SSL
Käivitamiseks piisab
/etc/init.d/apache2 start
selleks et peale rebooti automaatselt stardiks
rc-update add apache2 default
httpd.conf
Apache httpd.conf võib luua sarnaselt. Siin toodud seadistus on täiesti universaalne ja operatsioonisüsteemist sõltumatu
Listen 443 NameVirtualHost ip-aadress:443 <VirtualHost ip-aadress:443> ServerName www.nimi.ee DocumentRoot /home/nimi SSLEngine on SSLCertificateFile /rada/sertifikaadini/server.crt SSLCertificateKeyFile /rada/sertifikaadini/server.key </VirtualHost>
Erinevate namebased virtualhostide juures saab sertifikaate kasutada
vaid siis kui sertifikaat Subject Alternative Name abil on defineeritud kõik domeenid sertifikaati!
http://www.onlamp.com/pub/a/apache/2005/02/17/apacheckbk.html
Ametlikud sertifikaadid
Teine lahendamist vajav asi on see, et tuleb luu olukord, kus:
- klient saab olla kindel, et server mida ta külastab on ikka see mis ta paistab olevat (nt. www.eyp.ee) - server saab olla kindel, et klient on see kes ta ütleb end olevat
Osutub, et antud juhul on vaja kolmandat instanssi kes jagab välja 'pileteid'. Nii peab server omama autoriteetse instansi poolt väljastatud sertifikaati kus on sees instansi poolt signeeritud info selle kohta, et vot selle sertifikaadi esitaja on tõepoolest www.eyp.ee; sarnaselt on võimalik igal kliendil omandada sellelaadne sertifikaat kus instans on signeerinud, et jah, selle seritifikaadi esitaja on see ja see.
Reaalses elus tegutseb 'instansi'ina organisatsioon Verysign. Kuigi praktiliselt on nii, et krüpteeritud liiklust lubavad serverid ei hooli kas kliendil on või pole sertifikaati. Kliendi nö. isik tehakse parooli sisestamisega kindlaks. See on turvaline kuivõrd toimub juba krüpteeritud seansi sees. Aga klient peab hoolima küll, et server keda ta külastab oleks 'instansi' poolt sertifitseeritud.