-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Izviniavaim se, che tolkova kyseno propisah po obeshtanata tema. Opravdanieto e kato zadnika - vseki si go ima i zatova shte vi spestia opravdaniata si.
============================================================ Prelude: Na syvremenoto nivo na razvitie na t.nar. VPN (Virtual Private Network) vse po-ostro se chuvstva nuzhdata ot izpolzvaneto na nadezhden udostoveritelen model. Tova e prodiktuvano 1) ot vse po-strogite standarti kym opazvane na senzitivnata vytreshno- firmena ili vytreshnovedomstvena informacia ot neotoriziran dostyp pri prenosa i prez Internet mezhdu razlichnite klonove na firmenata i organizacionna struktura; 2) ot nuzhdata za edinen dostyp do vsichki spodeleni resursi, vkliuchitelno i vkliuchvaneto kym VPN na nestacionarni mashini (roadwarriors) chrez edna autorizacia. Iasno e, che starite shemi za authentikacia, kato tezi s parola ili kato tezi podchineni na sydyrzhanieto na KEY RR v zonite na domeinite veche sa pod dopustimite normi za sigurnost vyzprieti ot golemite kompanii, voennite i bankoviat sector v razvitite strani. M/u drugoto Microsoft oshte izpolzva shemi bazirani na RSA publichni kliuchove asociirani s KEY RR vypreki, che mnogo companii za analiz na mrezhovata sigurnost (Counterpane naprimer) redovno po forumi i konferencii, kakto i v statii pokazvat serioznite propuski nalichni v tozi vid udostoveriavane. Po princip politica na Microsoft e da ne se vslushvat v glasa na experite po sigurnost. Plod na tazi politica sa serioznite propuski v sigurnostta na Active Domain Controller shemata. V momenta se oformat dva visokotehnologichni standarta za udostoveriavane : 1) necentraliciran - baziran na OpenPGP certificaten model. Tozi model e mozhe bi nai-dobriat nalichen zasega model, zashtoto osven visoka sigurnost (otvoren standart, osnovnite prilozhenia sa s otvoren code, izpolzvat se samo nekompromentirani crypto algoritmi) ima i shematichno perfectna (za tozi vid modeli) infrastructura na publichnia kliuch (PKI); 2) centraliziran - baziran na X.509 certificaten mode. Tozi model e nai- izpolzvania za sega certificaten model. Izgraden e na ideiata za edinen udostoveritel. Ne pozvoliava krystosani shemi na vzaimno udostoveriavane. Edinniat udostoveritel v modela se naricha Certificate Authority (CA). Shemata deistva blagodarenie na doverieto na klientite na udostoveritelia kym nego. Modelyt izpolzva oshte dosta ostareli symmetrichni algoritmi (uchudvashto e zashto oshte se izpolzvat RC2 i RC4, kakto i DES). Dopuska izpozvaneto na Anonymous Diffie-Hellman systema za obmen na symmetrichni kliuchove, koiato poniakoga mozhe da komprometira samoto udostoveriavane. Da ne govorim za istinskia monopol, koito pozvoliava PKI na tozi vid certificate. Remark: Tuk shte pokazhem kak X.509 certificatnia model mozhe da byde vpregnat da izvyrshva bezopasna za izpolzvashtite udostoveritelna deinost. =========================================================== V sveta na OpenSource resheniata realizatora na X.509 shemata e paketa OpenSSL. Zhelatelno e da izteglite poslednata versia na paketa ot http://www.opsnssl.org. Molia vnimatelno proverete cifrovia OpenPGP podpis na paketa predi da go kompilirate i izpolzvate. OpenPGP certificate-a na proekta mozhete da izteglite ot 2 ili poveche keyserver-a. Sravnete kopiata vyrhu otdelnite keyserveri (po-specialno proverete fingeprinta). Ako vsichki kopia sa nared, importiraite certificate-a na projecta vyv pubringa-a na vashiata GNUPG. Proverete cifrovia podpis izvyrshen vyrhu paketa openssl, koito ste izteglili. Ako proverkata mine uspeshno razpaketiraite v otdelna directoria. Napravete konfiguracia, koiato da instalira paketa v otdelna directoria, koiato da se izpolzva SAMO za nuzhdite na CA, no ne i ot prilozheniata. Po podrazbirane OpenSSL shte instalira vsichki cipheri nalichni v paketa. Imaite predvid, che niakoi distrubucii kato RedHat, koito strogo se pridyrzhat kym licenzionnite normi i patentnite zakonodatelstva ne kompilirat paketa s poddryzhka na symmetrichnia cryptoalgoritym IDEA. Zatova e dobre da kompilirate vasha versia na paketa, za da niama lipsi. Dobre e da ne instalirate vashata compilacia vyrhu systemata za da na prichinite konflicti, osobeno ako vyvhu systemata ima instaliran ot paketna systema paket OpenSSL. Eto edin primer: ./Configure --prefix=/home/CA --openssldir=/home/CA linux-elf Taka shte izberete directoriata /home/CA za miasto na vashta compilacia na paketa OpenSSL. Ako vse pak iskate da premahnete IDEA (naprimer vie ste izvyn Bulgaria, v strana, v koiato IDEA e patentovan) mozhte da izpolzvate slednia commanden red za configuraciata: ./Configure --prefix=/home/CA --openssldir=/home/CA no-idea linux-elf Sledva gmake i gmake install, s koeto v /home/CA shte imate instalirana vasha compilacia na paketa OpenSSL. Dobre e da izpylnite: chown -R root.root /home/CA ako veche e bila syzdadena /home/CA i e bila vyvedena v sobstvenot na user razlichen ot root. Syshto taka: chmod 700 /home/CA Pyrvoto, s koeto shte se zaemem e redakcia na configuracionnia file openssl.cnf. V nego traibva da se promeniat naikolkoto poleta za da mozhe da se dostigne do maximalnoto nivo na sigurnost. Samiata file se namira v /home/CA (ako ste sledvali gornia primer). vi /home/CA/openssl.cnf 1) v sekciata [ CA_default ] dir = /home/CA # Where everything is kept default_md = sha1 # which md to use. (ne izpolzvaite MD5) 2) v sekciata [req] default_bits = 4096 3) v sekciata [ req_attributes ] challengePassword_min = 10 challengePassword_max = 100 Zapishete promenite. Sega sledva da generirate OpenSSL X.509 samopodpisan certificate, koito shte e osnovata na vashta CA. Tova generirane po princip mozhe da byde napraveno v command line chrez izvikvaneto na binarnia file /home/CA/bin/openssl, no OpenSSL predlaga edin udoben shell script, s koito mozhete da svyrshite tazi rabota s malko pisane. Tozi script se namira v /home/CA/misc i se naricha CA.sh (ima i CA.pl, no tozi iziskva da imate instaliran Perl v systemata si). Predi da go izpolzvame CA.sh e dobre da se napraviat niakoi redakcii. vi /home/CA/misc/CA.sh DAYS="-days 1825" #CA cert. shte e validen 5 godini REQ="/home/CA/bin/openssl req -config /home/CA/openssl.cnf" CA="/home/CA/bin/openssl ca -config /home/CA/openssl.cnf" VERIFY="/home/CA/bin/openssl verify" X509="/home/CA/bin/openssl x509" promenete tozi cegment ot tozi vid (namira se pod -newca) echo "Making CA certificate ..." $REQ -new -x509 -keyout ${CATOP}/private/$CAKEY \ -out ${CATOP}/$CACERT $DAYS RET=$? v slednia vid echo "Making CA certificate ..." $REQ -new -x509 -sha1 -keyout ${CATOP}/private/$CAKEY \ -out ${CATOP}/$CACERT $DAYS RET=$? (zabelezhete prisystvieto na -sha1) Zapazete promenite i pristypvame kym generirane na CA X.509 certificate: /home/CA/misc/CA.sh -newca Shte bydete zapitani za parola za zashtita na chastnia kliuch na CA. Parolata traibva da e po-dylga ot 20 simvola i da izpylniava iziskvaneto na maximalna entropia na simvolnoto mnogoobrazie izpolzvano v neia. Symmetrichnia algoritum chrez koito se kodira chastnia kliuch e 3DES s dylzhina na kliucha 168 bita (3x56 bita - zatova se i naricha 3DES :)) ). Napylno nadezhden v dneshno vreme. Sled kato vyvedete parolata shte traibva da vyvedete LDAP formatnite poleta na certificate-a. Sled kato vyvedete stoinostite na tezi poleta veche imate zavyrshen X.509 podpisan certificate. Chastnia kliuch na CA shte se namira v /home/CA/private i shte se naricha cakey.pem (ako iskate da promenite tova ime, otidete v openssl.cnf i go smenete). Zadaite chmod 600 na /home/CA/private/cakey.pem. X.509 sertificata na CA shte namerite v /home/CA i shte se naricha cacert.pem. Lesno mozhete da vidite informaciata za certificate-a chrez /home/CA/bin/openssl x509 -text -in /home/CA/cacert.pem ========================================================= Generiane na potrebitelski certificates i podpisvaneto im Remarks: Porochna (da ne kazha prestypna) praktika na mnogo CA po sveta i u nas e te da generirat chastnia kliuch na clienta. Tova napylno oporochava shemata na udostoveriavane, zashtoto pravi CA ne samo udostoveritel, a i sobstvenik na certificate-a na clienta i mozhe da se predstavia kato nego! Tazi porochna shema se praktikuva shiroko i ima pochva edinstveno na bazata na negramotnostta na potrebitelia. Zapomnete! Chastnia kliuch e sobstveno EDINSTVENO i SAMO na clienta. CA samo podpisva certificate-a i ne pravi nishto drugo ot technicheska gledna tochka. Kak clienta da generira chasten kliuch? Tova stava chrez nalichnata na negovata systema instalacia na OpenSSL. Preporychaite na clienta da generira certificate s dylzhina na chastnia kliuch ne po-malka ot 2048 bita. Pri syvremenite computri tova ne e baven proces, a i sled tova ne bavi koi znae kolko uostoveritelnia proces "client-server". 1) generirane na chasten RSA kliuch s dylzhina 2048 bita i kodiran s 3DES: openssl genrsa -des3 -out newkey.pem 2048 2) generirane na zaiavka kym CA za izdavane na X.509 clientski certificate: openssl req -new -sha1 -key newkey.pem -out newreq.pem Ukazhete chalenge password koito posle da mozhe da se izpolzva v PKCS#12 user certificates. Failyt newreq.pem se zanasia v CA za podpis. Failyt newkey.pem ne se nosi v CA i CA ne mozhe da go iska. Niama nikakvo osnovanie za tova. CA podpisva newreq.pem po slednia nachin /home/CA/misc/CA.sh -sign Shte se poluchi nov file s ime newcert.pem. Tova e podpisania clientski X.509 certificate. Toi se dava na clienta. Taka clientyt veche ima podpisan X.509 certificate i tova e pyrvata chast pri setup-a na X.509 bazirania FreeS/WAN. ========================================================== VNIMANIE! CA traibva da osiguri dostyp do svoia publichen klich cacert.pem za vseki zainteresovan za tova potrebitel. Nai-udobno e tozi certificate da se dava napravo na vseki client pri podpisvaneto na negovia X.509 certificate i da e nalichen syshto na web saita na CA. Potrebiteliat, koito pritezhava newkey.pem i newcert.pem mozhe da napravi sam svoi PKCS#12 certificate, koito da se izpolzva za authentikacia chrez browseri, E-mail clienti poddryzhashti standarta PEM i dr. Kym PKCS#12 mozhe da se pribavi i CA certificate (makar tova da ne e zadylzhitelno). Eto edin primer na izgrazhdane na PKCS#12. Failovete newcert.pem, newkey.pem i cacert.pem se sybirat v edna directoria. Sled tova: cat newkey.pem newcert.pem cacert.pem > proto.pem openssl pkcs12 -descert -export -in proto.pem -name "My PKCS#12" VNIMANIE! Ne izpuskaite opciata -descert. Inache po podrazbirane PKCS#12 se cryptira s RC2 algoritym s dylzhina na kliucha 40 bita, koeto e tvyrde slaba zashtita v dneshno vreme. -descert kriptira PKCS#12 chrez 3DES (168 bitov kliuch). ============================================================= V sledvashtia posting shte poiasnia kak stava configuraciata na FreeS/WAN chrez izpolzvaneto na X.509 bazirani certificates. Pozdravi Beco -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/Tb/b+48lZPXaa+MRAr6dAJ0VpbweDqti8jvZwVDq0ot9TeAvNwCfUIg1 j3bZjWm7mZ8+0s+Xaj3PF4c= =GCSo -----END PGP SIGNATURE----- ============================================================================ A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers). http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html ============================================================================
