Instalacja i konfiguracja Apache SSL

Kryptografia i Ochrona Danych

Instalacja i Konfiguracja

Apache-SSL

Autor: Pawe Dynarowski

Luty 2002

Spis tre´

sci

Wst

ep teoretyczny

1.1

Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2

Protok´

o l HTTP i serwer Apache . . . . . . . . . . . . . . . . .

1.3

Identyfikacja i poufno´s´

c danych . . . . . . . . . . . . . . . . .

1.4

Infrastruktura kluczy i certyfikaty cyfrowe . . . . . . . . . . .

1.5

ecej o protokole SSL . . . . . . . . . . . . . . . . . . . . . .

Apache realizuj

acy protok´

o l HTTPS

2.1

Instalacja SSL . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2

Instalacja nak ladki Apache-SSL . . . . . . . . . . . . . . . . .

2.3

Konfiguracja Apache’a do wsp´

o lpracy z SSL . . . . . . . . . .

2.3.1

Wsp´

o lpraca tylko z SSL . . . . . . . . . . . . . . . . .

2.3.2

Jednoczesna obs luga witryn z SSL i bez SSL . . . . . .

2.4

Tworzenie certyfikat´

ow . . . . . . . . . . . . . . . . . . . . . .

2.5

Przyk ladowe certyfikaty

. . . . . . . . . . . . . . . . . . . . .

2.6

Przyk ladowa konfiguracja

. . . . . . . . . . . . . . . . . . . .

2.7

Efektywno´s´

c . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Wst

ep teoretyczny

1.1

Wprowadzenie

Na pocz

atku pracy nale˙zy wspomnie´

c, ˙ze ˙zaden dokument RFC nie okre´sla

protoko lu HTTPS. Protoko lem HTTPS okre´slamy normalny protok´

o l HTTP

zabezbieczony protoko lem SSL. Protok´

o l HTTP ( HyperText Transfer Pro-

tocol) s lu˙zy do porozumiewania si

e pomi

edzy klientami i serwerami sieci

WWW. Natomiast SSL (Secure Socket Layer) jest protoko lem og´

olnego przez-

naczenia wykorzystywanym do przesy lania zaszyfrowanych informacji za po-
moc

a internetu . Podstawowym wymaganiem, kt´

ore nale˙zy spa lni´

c w celu

skutecznego wykorzystania ktyptografii klucza publicznego w komunikacji in-
ternetowej, jest ujednolicenie mechanizm´

ow kryptograficznych u˙zywanych w

serwerach WWW i przegl

adarkach. Ton ca lej dyskusji nada la ju˙z jaki´s czas

temu firma Netscape Communications, wprowadzaj

ac protok´

o l szyfruj

acy

SSL, wykorzystuj

acy algorytmy szyfrowania asymetrycznego i w chwili obec-

nej wyznaczaj

acy standard w´sr´

od aplikacji zawi

azanych z WWW. Z pro-

toko lem SSL konkurowa lo kilka innych rozwi

aza´

n, mi

edzy innymi niezbyt

rozpowszechniony protok´

o l SHTTP (Secure HyperText Transfer Protocol)

i opracowany przez zesp´

o l IRTF (Internet Engineering Task Force) pro-

tok´

o l TLS (Transport Layer Security), kt´

ory mia l zast

api´

c SSL. Prace nad

protoko lem TLS jednak ostatecznie przerwano i na polu bezpiecznych pro-
toko l´

ow internetowych pozosta l jedynie u˙zywany dzi´s powszechnie protok´

o l

SSL.

1.2

Protok´

o l HTTP i serwer Apache

Wszystkie transakcje HTTP budowane s

a na podstawie tego samego zasad-

niczego schematu wsk lad kt´

orego wchodz

a: zapytanie(ze strony klienta) lub

status odpowiedzi (ze strony serwera), nag l´

owek - ko´

ncz

acy si

e pust

a lini

a -

oraz tre´s´

Klient HTTP (przegl

adarka internetowa, np. Netscape Navigator lub Mi-

crosoft Internet Explorer) l

aczy si

e z serwerem HTTP (zwanym inczej ser-

werem WWW) na porcie o okre´slonym numerze (domy´slnie jest to port
80 ). Nast

epnie klient wysy la zapytanie o dokument. Dokumentem mo˙ze

by´

c r´

ownie˙z program, kt´

orego wyniki nale˙zy zwr´

oci´

c klientowi. Nast

epnie

przesy lany jest nag l´

owek, zawieraj

acy opcjonalne informacje o konfiguracji

klienta oraz opcjonalne dane dodatkowe.
Serwer WWW wysy la odpowied´

z zawieraj

a wersj

e protoko lu, kod odpowiedzi

i jego opis (pierwsza linia odpowiedzi zwana lini

a stanu). Nast

epnie przesy la

nag l´

owek zawieraj

acy dane dotycz

ace serwera i przesy lanego dokumentu (przede

wszystkim format daych), a nast

epnie przesy la sam dokument, kt´

orym mo˙ze

by´

c r´

ownie˙z, jak ju˙z wspomniano, odpowied´

z programu, dzia laj

acego zgod-

nie z mechanizmem wsp´

olnego interfejsu bramy (ang. Common Gateway

Interface, CGI).

Najpopularniejszym w chwili obecnej serwerem WWW jest Apache. Mia l

on niezaprzeczalny wp lyw na rozw´

oj sieci WWW, przede wszystkim dzi

eki

temu, ˙ze jest ca lkowicie darmowy, latwodost

epny, do´s´

c bezpieczny (dzi

eki

strukturze system´

ow operacyjnych rodziny Unix, dla kt´

orej zosta l stwor-

zony), szybki, udost

epnia bardzo rozbudowany i latwo rozszerzalny wach-

larz format´

ow danych, a przede wszystkim stale si

e rozwija. Apache oparty

zosta l na kodzie i rozwi

azaniach zastosowanych w programie opracowanym w

NCSA (National Center for Supercomputing Applications, USA), kt´

ore jest

agend

a rz

adu Stan´

ow Zjednoczonych.

Obecnie najnowsz

a wersj

a Apache’a jest Apache-1.3.22. Co prawda spotka lem

sie juz z wersj

a Apache-2.0.28 ale by la to wersja alfa i ze wzgl

edu na ewen-

tualne b l

edy i dziury nie zaleca si

e jej narazie instalowa´

1.3

Identyfikacja i poufno´

s´

c danych

Sie´

c internetowa stworzy la cz lowiekowi niesamowit

a mo˙zliwo´s´

c pozostawania

anonimowym. Istniej

a jednak sytuacje, w kt´

orych wszyscy chcieliby mie´

pewno´s´

c co do to˙zsamo´sci os´

ob, z kt´

orymi si

e kontaktuj

a. Wi

ekszo´s´

c takich

sytuacji dotyczy sfery finansowej.
We wsp´

o lczesnym ´swiecie umowy mi

edzyludzkie opieraj

a si

e na zaufaniu.

Dotyczy to chocia˙zby wypo˙zyczenia ksi

a˙zki z biblioteki (biblioteka ufa, ˙ze zwr´

ksi

a˙zk

e), zawierania umowy kredytu (bank ufa, ˙ze kredyt sp lac

e) czy p lacenia

kart

a kredytow

a (sklep ufa, ˙ze bank zap laci za towar z mojego konta). Zau-

fanie to opiera si

e na prawnej ochronie stanowionej przez pa´

nstwo (pa´

nstwo

mo˙ze ograniczy´

c moj

a wolno´s´

c i zmusi´

c mnie do wywi

azania si

e z umowy)

oraz na identyfikacji mnie, jako strony umowy. Bez pewnej identyfikacji nie
by loby mo˙zliwe okre´slenie kto by l stron

a umowy.

Identyfikacja w ´swiecie realnym opiera si

e na trudnych do podrobienia

dokumentach wydawanych przez organy pa´

nstwowe, na umieszczonych w

tych dokumentah zdj

eciach, kt´

ore powinno by´

c bardzo trudno podmieni´

c bez

zniszczenia dokumentu i na naszym w lasnor

ecznym podpisie. Jest to zesp´

o l

dobrze funkcjonuj

acych, sprawdzonych i ci

agle rozwijanych rozwi

aza´

n, ale

pomimo tego zdarzaj

a si

e do´s´

c cz

esto przest

epstwa.

Internet postawi l w tej dziedzinie nowe wyzwania. Umowy (jak chocia˙zby

zap lata kart

a kredytow

a) s

a zawierane bez fizycznej obecno´sci cz lowieka.

P lac

ac chcemy mie´

c pewno´s´

c, ˙ze naprawd

e nasze pieni

adze dotr

a do sklepu,

a nie do kogo´s kto si

e pod sklep ,,podszywa”. Poniewa˙z do zap laty wystar-

czy kilka cyfr (numer karty i jej data wa˙zno´sci) zale˙zy nam by danych tych
nie pozna l nikt poza osobami uprawnionymi. Niezb

edne opr´

ocz identyfikacji

okaza lo si

e szyfrowanie danych, i to jak najbardziej zaawansowane. Tak za-

awansowane, by przest

epcy nie op laca lo si

e inwestowa´

c w odszyfrowywanie

danych, a z drugiej strony z punktu widzenia pa´

nstwa (szczeg´

olnie jego

s lu˙zb bezpiecze´

nstwa), by jego s lu˙zby mog ly odszyfrowa´

c dane np. obcych

wywiad´

ow.

1.4

Infrastruktura kluczy i certyfikaty cyfrowe

Najbardziej popularne techniki identyfikacji stosowane w internecie wyko-
rzystuj

a systemy bazuj

ace na has lach, na przedmiotach (np. tokeny wydawane

przez banki) lub na biometrykach (np. odciski palc´

ow). Za najlepsze ulep-

szenie tych system´

ow, dzia laj

ace cz

esto nawet samodzielnie, uznaje si

e tech-

nologi

e systemu podpis´

ow cyfrowych tworzonych za pomoc

a pary kluczy:

prywatnego i publicznego. Przy pomocy klucza prywatnego, znanego tylko
w la´scicielowi, podpisuje on (np.

do l

aczaj

ac go do danych lub szyfruj

nim dane) wysy lane dane. Odbiorca, kt´

ory wcze´sniej otrzyma l od nadawcy

jego klucz publiczny, za pomoc

a tego klucza publicznego odczytuje podpis

(lub dane gdy s

a zaszyfrowane) i je´sli odszyfrowanie si

e powiod lo mo˙ze by´

pewien, ˙ze . . . wiadomo´s´

c wys la l posiadacz danego klucza prywatnego. Dany

klucz publiczny jest jedynym, kt´

orym wiadomo´s´

c zaszyfrowan

a przy pomocy

odpowiadaj

acego mu klucza prywatnego mo˙zna odszyfrowa´

Klucz pry-

watny powinien wi

ec by´

c bardzo pilnie strze˙zony, przechowywany w postaci

zaszyfrowanej, chroniony has lem. Pomimo tego, w standardowych rozwi

azaniach

dla wykonania z jego pomoc

a szyfrowania, musi i tak by´

c w chwili szyfrowania

odkodowany i przechowywany w pami

eci komputera, co szczeg´

olnie nara˙za

go na przej

ecie. Najbardziej zaawansowane w tej chwili rozwi

azania pole-

gaj

a na przechowywaniu par kluczy na karcie elektronicznej z mikroproce-

sorem, kt´

ora otrzymuje wiadomo´sci i dokonuje na nich operacji. Jest to wi

sprz

etowa implementacja tej technologii, a jej bezpiecze´

nstwo zale˙zy od fizy-

cznego zabezpieczenia urz

adzenia.

Kolejnym wyzwaniem by lo zapewnienie, ˙ze osoba lub firma identyfikuj

aca

e dan

a par

a kluczy, to naprawd

e ta osoba. W tym celu powsta ly urz

edy

certyfikacji (ang. Certification Authority, CA). Za pomoc

a swoich kluczy pry-

watnych CA podpisuj

a klucze publiczne sprawdzonych przez siebie w ´swiecie

rzeczywstych firm lub os´

ob. Najbardziej znane CA to GTE Cyber Trust,

TC Trust Center, Thawte i Verisign (dawne RSA - firma za lo˙zona przez
p´

o´

zniejszych profesor´

ow MIT (Massachusetts Institute of Technology) - Ronalda

Rivesa, Adi Shamira i Leonarda Adlemana, autor´

ow jednego z najpopu-

larniejszych algorytm´

ow kryptograficznych opartych na parze kluczy - algo-

rytmu RSA). Ka˙zda taka firma wydaje oficjalny dokument ,,Za lo˙zenia poli-
tyki certyfikacji” (ang. Certification Practises Statement, CPS), opisuj

acy

metody przyznawania i cofania certyfikat´

ow.

Podstawowym standardem certyfikatu, rekomendowanym przez Mi

edzynarodow

Uni

e Telekomunikacyjn

a (ang. International Telecommunication Union, ITU-

T ), wykorzystywanym w protokole SSL jest X.509 v3. Sk lada si

e on z numeru

wersji, numeru seryjnego, danych identyfikacyjnych, informacji o stosowanym
algorytmie, danych podpisuj

acego i podpisywanego, daty wydania i terminu

wa˙zno´sci. W formie zakodowanej jest on przechowywany jako pilk tekstowy
w formacie okre´slonym jako PEM.

1.5

ecej o protokole SSL

Protok´

o l SSL tworzy warstw

e rozdzielaj

a podstawowy protok´

o l TCP/IP

- odpowiedzialny za tworzenie po l

acze´

n, przesy lanie anonimowych strumieni

informacji i obs luguj

acy b l

edy - oraz warstw

e aplikacji. Mo˙ze tak˙ze pracowa´

z innymi protoko lami warstwy transportowej je´sli zapewniaj

a wysok

a nieza-

wodno´s´

c. Cho´

c SSL zosta l zaprojektowany do zabezpieczenia protoko lu http,

istniej

a ju˙z rozwi

azania zabezpieczaj

ace protoko ly smtp , pop3.

SSL zapewnia:

• uwierzytelnianie i niezaprzeczalno´s´c serwera i klienta dzi

eki wykorzys-

taniu podpis´

ow cyfrowych,

• poufno´s´c wymiany danych poprzez wykorzystanie szyfrowania,

• integralno´s´c danych dzi

eki wykorzystaniu kod´

ow uwierzytelniaj

acych

wiadomo´sci.

Do realizacji ka˙zdej z powy˙zszych trzech r´

ol wykorzystuje odr

ebne algorytmy,

kt´

ore to wykorzystuj

a dodatkowo odr

ebne klucze, dzi

eki czemu restrykcje

wielu pa´

nstw dotycz

ace technologii szyfrowania tre´sci (np. Stany Zjednoc-

zone - zabroniony eksport najnowszych technologii, Francja - szyfrowanie
prawnie zabronione), nie ograniczaj

a bezpiecze´

nstwa uwierzytelniania i iden-

tyfikacji.

OpensSSL jest najpopularniejsz

a darmow

a implementacj

a SSL dla sys-

tem´

ow operacyjnych rodziny Unix, a jej jako´s´

c nie odbiega od produkt´

komercyjnych. Bazuje na bibliotece SSLLeay. OpenSSL zosta l stworzony
przez Ralfa Engelshalla z Wydzia lu Elektrycznego Swiss Federal Institute of
Technology. Obs luguje protoko ly SSLv2, SSLv3 i jego nast

epn

a wersje TLS,

nad kt´

a prace ostatecznie zosta ly zako´

nczone. Z algorytm´

ow szyfruj

acych

wykorzystuje m.in DES, IDEA i Triple-DES. Obecnie najnowsz

a dost

epn

wersj

a OpenSSL’a jest OpenSSL-0.9.6c. Dost

epna jest ona mi

edzy innymi

na stronie www.apache-ssl.org.

Apache realizuj

acy protok´

o l HTTPS

Aby serwer WWW (np. Apache) m´

og l korzysta´

c z warstwy SSL (np. dzia laj

acej

dzi

eki bibliotece OpenSSL) niezb

edne jest jego uzupe lnienie o ,, l

acznik”. Jed-

nym z ma˙zliwych rozszerze´

n serwera Apache o mo˙zliwo´s´

c realizowania pro-

toko lu SSL jest stworzony przez Bena Lauriego, jednego z tw´

orc´

ow Apache’a,

Apache-SSL. Narz

edzie to wymaga rekompilacji serwera Apache o ile by l on

wcze´sniej zainstalowany. Wraz z wprowadzeniem do serwera Apache tech-
nologii modu l´

ow ladowalnych powsta l w kwietniu 1998 modu l mod ssl, au-

torstwa Ralfa S. Engelshalla, autora OpenSSLa. Wersja 2.0 opublikowana
w sierpniu 1998 nie by la ju˙z oparta na Apache-SSL’u. Teoretycznie mod ssl
nie wymaga rekompilacji serwera apache. w praktyce jest troche inaczej,
poniwa˙z mod ssl wymaga aby wcze´sniej Apache by l skompilowany z rozszer-
zonym interfejsem API zwanym EAPI, co w standardowej instalacji nie jest
wykonywane, wi

ec je´sli administrator nie przewidywa l od pocz

atku potrzeby

instalacji mod ssl i tak wymagana jest rekompilacja Apache’a).

W naszym przypadku do realizacji protoko lu HTTPS u˙zyli´smy Apache-

ssl(nie myli´

c z mod ssl co podkre´sla sam producent na swojej stronie inter-

netowej www.apache-ssl.org).

2.1

Instalacja SSL

Obecnie przedstawimy opis czynno´sci maj

acych na celu stworzenie wersji ser-

wera apache obs luguj

acej wymian

e danych w protokole HTTPS. Pierwszym

etapem b

edzie zdobycie kodu biblioteki Openssl-0.9.6c. Mo˙zna j

a sci

agn´

jak ju˙z wcze´sniej wspomnia lem ze strony www.apache-ssl.org. Najlepiej

˙zeby by la to wersja o kt´

orej pisz

e poniewa˙z z wersjami nieco starszymi np.

Openssl-0.9.6b mia lem problemy z ich kompilacj

a.Z niewiadomych do tej

pory przyczyn kompilator wyrzuca l komunikaty o b l

edach i przerywa l kom-

pilacj

e. W przypadku najnowszej wersji nie by lo najmniejszych problem´

ow.

Instalacj

e biblioteki zaczynamy od skopiowania jej do odpowiedniego kat-

alogu np. do /usr/local/ssl/. Nast

epnie nale˙zy j

a rozpakowa´

gzip -d openssl-0.9.6c
tar xvf openssl-0.9.6c

Efektem tego by lo pojawienie si

e podkatalogu openssl-0.9.6c zawieraj

acego

do´s´

c poka´

a liczb

e plik´

ow. Po przej´sciu do katalogu nale˙z zapozna´

c si

e z za-

warto´sci

a pliku INSTALL, w kt´

orym jest opisany przebieg instalacji Openssl’a.

Zgodnie z dokumentacj

a rozpocz

ecia procesu instalacji dokonuje si

e poprzez

wydanie polecenia - ./Configure [nazwa systemu]. W naszym przypadku
mia lo ono posta´

c :

./Confugure FreeBSD
Nast

epnie budujemy bibliotek

e wydaj

ac polecenie :

make
spowoduje zbudowanie bibliotek OpenSSL(libcrypto.a i libssl.a) i niezb

ednych

program´

ow. Biblioteki powinny zanjdowa´

c sie w katalogu g l´

ownym tzn.

/usr/local/ssl/ a aplkikacje w katalogu /apps. Je´

sli kompilacja zako´

nczy

sie powodzeniem nale˙zy przetestowa´

c biblioteki ,wydaj

ac polecenie :

make test
wynikiem ich wykonania jest multum wy´swietlanych na ekranie informacji,
kt´

ore dla przeci

etnego u˙zykownika s

a prawdopodobnie ma lo interesuj

ace i

nieczytelne. Ca lo´s´

c instalacji powinna zako´

nczy´

c sie wydrukiem certyfikatu

tekstowego o nazwie newcert.pem. Ostatnim krokiem instalacji jest wydanie
polecenia :
make install
Po wykoniu tego polecenia biblioteka OpenSSL znajduje sie juz w katalogu
/usr/local/ssl/.

Alternatyw

a dla OpenSSL mo˙ze by´

c SSLeay-0.9.0b. Jest ona jednak

nieco starsza i trudniejsza w konfiguracji. Spe lnia jednak tak

a sam

a rol

e jak

omawiana biblioteka OpenSSL-0.9.6c. Bibliotek

e t

a mo˙zna ´sci

agn

a´

c m.in z

ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL/.

2.2

Instalacja nak ladki Apache-SSL

Do zainstalowania Apache’a realizuj

acego protok´

o l SSL opr´

ocz opisanej wcze´sniej

biblioteki OpenSSL niezb

edne s

a jeszcze dwa pliki : aktualna wersja serwera

Apache (w naszym przypadku jest to apache 1.3.22 oraz specjalny patch
do tego serwera - apache 1.3.22+ssl 1.44. Przy czym nale˙zy wspomnie´

o jednej bardzo wa˙znej rzeczy - omawiana nak ladka powinna by´

c jak na-

jnowsza ale musi odpowiada´

c posiadanej przez nas wersji serwera Apache, w

przeciwnym razie instalacja si

e nie powiedzie.

Instalacje serwera Apache zaczynamy od usuni

ecia poprzedniej wersji ser-

wera na naszej maszynie - polecenie rm -R [katalog-apache]. Po ponownym
ropzakowaniu pliku .tar zawieraj

acego dystrybucj

e programu Apache i ut-

worzeniu odpowiedniego katalogu nale˙zy umie´sci´

c w nim patch, o kt´

orym

by la mowa wcze´sniej i rozpakowa´

c go :

tar -xzvff apache 1.3.22+ssl 1.44.tar.gz

otrzymuj

ac w efekcie zestaw plik´

ow rozszerzeniem .SSL.

Zgodnie z opisem podanym w pliku README.SSL kolejnym krokiem jest

wykonanie polecenia:
./FixPatch
Na pro´sb

e o potwierdzenie dokonania modyfikacji nale˙zy odpowiedzie´

c naciskaj

klawisz y.

W przypadku gdy nie uda nam sie zastosowa´

c patch’a lub zwr´

oci on nam

b l

ad nale˙zy sparawdzi´

c wersj

e posiadanego patcha (patch -version). Je´sli

jest on ni˙zszy od 2.1 to nale˙zy sci

agn

ac nowszy, bo to on jest najbardziej

prawdopodobn

a przyczyn

a b l

edu.

Teraz mo˙zemy przystpi´

c do kompilacji spatchowanego Apache’a:

./configure
--prefix=/usr/local/apache-ssl
--enable-module=rewrite
--enable-shared=rewrite
make
make install
Je´sli wszystko si

e uda lo mo˙zemy przej´s´

c do konfiguracji serwera . Nale˙zy

tego dokona´

c przed pierwszym uruchomieniem serwera.

2.3

Konfiguracja Apache’a do wsp´

o lpracy z SSL

2.3.1

Wsp´

o lpraca tylko z SSL

Poni˙zej opisz

e,ja skonfigurowa´

c Apache do wsp´

o lpracy TYLKO z SSL. Mo˙zna

te skonfigurowa´

c go tak, aby obs lugiwa l witryny zar´

owno z SSL, jak i bez

SSL.

Domy´slnie plik konfiguracyjny Apacha ma nazw httpsd.conf - niby

s lusznie- ale tw´

orcy serwera zapomnieli spaczowa´

c fragment Apacha, by ten

korzysta l z pliku o takiej w la´snie nazwie - Apache-SSL odwo luje si

e do pliku

httpd.conf przy uruchomieniu ...kt´

orego nie ma.Wiec tworzymy link sym-

boliczny:
cd /usr/local/apahe-ssl/conf
ln -s httpsd.conf httpd.conf
i ju˙z Apache przy starcie nie b

edzie krzycza l z tego powodu.

˙Zeby Apache-SSL prawid lowo wystartowa l, nale˙zy w nim troch

e pozmienia´

i dopisa´

c kilka rzeczy: - linijke Port 80 i Listen 80 zmieniamy na Port 443

i Listen 443 , ˙zeby nas luchiwa l na standardowym dla protoko lu https por-
cie.Nale˙zy jeszcze dopisa´

c kilka dyrektyw niezb

ednych do obs lugi SSL.Robimy

to w pliku httpsd.conf dodaj

ac nast

epuj

ace linijki (oboj

etnie w kt´

orym

miejscu ale byle nie przed lini

a o tre´sci AddModule apache ssl.c):

Port 443 -m´

owi, ˙ze dana konfiguracja - w tym przypadku sekcji global -

dotyczy witryny obs lugiwanej na porcie 443)

Listen 443 - nas luchiwanie serwera na porcie 443 - standardowy dla pro-

toko lu https)

SSLEnable (w l

acza obs lug

e SSL)

SSLCACertificatePath /usr/local/apache-ssl/conf/ssl - ´scie˙zka do kat-

alogu z certyfikatami

SSLCACertificateFile /usr/local/apache-ssl/conf/ssl/cacert.pem - cer-

tifikat instytucji, kt´

ora wystawi la certyfikat dla naszej witryny

SSLCertificateFile /usr/local/apache-ssl/conf/ssl/newcert.pem - cer-

tyfikat wystawiony dla naszej witryny

SSLCertificateKeyFile /usr/local/apache-ssl/conf/ssl/newreq.pem

- klucz prywatny powy˙zszego certyfikatu

SSLCacheServerPort 8080 - port gcache’a

SSLCacheServerPath /usr/local/apache-ssl/bin/gcache - ´scie˙zka do

programu gcache

SSLSessionCacheTimeout 10000 ( timeout )

Jeszcze przed uruchomieniem Apache’a nale˙zy zgra´

c wygenerowane wcze´sniej

certyfikaty do katalogu /usr/local/apache-ssl/conf/ssl (katalog ten trzeba
wcze´sniej za lo˙zy´

c).Nale˙zy skopiowa´

c te pliki do wymienionych katalog´

ow:

/usr/local/openssl/ssl/misc/demoCA/cacert.pem
/usr/local/openssl/ssl/misc/newreq.pem
/usr/local/openssl/ssl/misc/newcert.pem

˙Zeby sprawdzi´c, czy w pliku konfiguracyjnym nie ma b l

ed´

ow, nale˙zy

urucjomi´

/usr/local/apache-ssl/bin/httpsdctl configtest.
Je˙zeli wyskoczy napis ’ok’, mo˙zemy przyst

api´

c do uruchomienia Apache’a

poleceniem:
/usr/local/apache-ssl/bin/httpsdctl start.
Aby sprawdzi´

c czy serwer Apache zosta l uruchomiony mo˙zemy wyda´

c polece-

nie ps -aux, kt´

ore wy´swietla informacje o wszystkich aktywnych proce-

sach w systemie. Powinno si

e tam znajdowa´

c 5 proces´

ow o nazwie httpsd.

W la´scicielem pierwszego powinien by´

c root a pozosta lych u˙zytkownik o

nazwie www nale˙z

acy do grupy www.Nie nale˙zy sie tym zbytnio przejmowa´

poniewa˙z g l´

owny proces nale˙z

acy do roota w odr´

o˙znieniu od pozosta lych nie

odbiera pojawiaj

acych sie w nim ˙z

ada´

n, a musi on by´

c on by´

c w la´scicielem

tego procesu, gdzy˙z tylko on jest uprawniony do odwo lywania si

e do port´

o numerach mniejszych ni˙z 1024.Zadaniem tego procesu jest zarz

adzanie po-

zosta lymi kopiami. W pliku konfiguracyjnym(httpsd.conf) musi te˙z znaj-
dowa´

c si

e odpowiedni wpis:

User www
Group www
U˙zytkownik ten nie mo˙ze te˙z mie´

c prawa wykonywania ˙zadnych program´

ow,

kt´

ore nie s

a przeznaczone do uruchomienia w odpowiedzi na ˙z

adania obs lugiwane

przez program httpsd.Przed uruchomieniem serwera nale˙zy jeszcze okre´sli´

jego nazwe pod kt´

a b

edzie widzoczny w sieci. Robimy to umieszczaj

ac w

pliku httpsd.conf wpis:
ServerName nazwaserwer.domena
W tej chwili serwer jest gotowy do uruchomienia.

Teraz tylko za pomoc

a przegldarki wchodzimy na stron

e o adresie :

https://www.adres.naszej.strony.pl/.Je´sli przegl

adarka znajdzie nasz

a stron

i pojawi si

e komunikat typu: ’Za chwil

e obejrzysz strony w bezpiecznym

po l

aczeniu’ to znaczy, ˙ze instalacja przebieg la prawid lowo.

2.3.2

Jednoczesna obs luga witryn z SSL i bez SSL

Jednoczesn

a obs lug

e witryn z SSL i bez SSL mo˙zna zrobi´

c na 2 sposoby.

Mo˙zna uruchomi´

c dwa Apache’y - jeden nas luchuj

acy na porcie 80 i serwuj

acy

witryny bez SSL, a drugiego uruchomi´

c na porcie 443 i skonfigurowa´

c go

do serwowania witryn SSL. Sposobu konfiguracji w ten spos´

ob chyba nie

trzeba opisywa´

c. Zatem drugi spos´

ob - odpali´

c jedn

a kopi

e Apache, kt´

ory by

serwowa l jednocze´snie witryny z, jak i bez SSL. W tym przypadku kompilacja
odbywa si

e tak samo, jak opisana powy˙zej do obs lugi SSL. Jedyn

a niewielk

r´

o˙znic

a b

edzie konfiguracja serwera Apache. W pliku httpsd.conf w sekcji

global musi si znale´

z´

c nast

epuj

acy wpis:

Listen 80
Listen 443
Port 80
co zmusi Apache’a do nas luchiwania na porcie 80 i dodatkowo na 443 (wi

ecej

na ten temat w dokumentacji Apache), a Port 80 m´

owi mu, ˙ze konfiguracja

sekcji GLOBAL dotyczy portu 80.

Teraz mo˙zemy przystpi´

c do konfiguracji server´

ow wirtualnych. Przyk ladowa

konfiguracja dw´

och serwer´

ow wirtualnyc (jeden z SSL, drugi bez) wygl

ada

nast

epuj

aco:

NameVirtualHost 212.212.212.212:80

NameVirtualHost 212.212.212.212:443
<VirtualHost 212.212.212.212:80>
DocumentRoot /www/NaszaDomenaBezSsl
ServerName www.NaszaDomenaBezSsl.pl
SSLDisable
...
</VirtualHost>
<VirtualHost 212.212.212.212:80>
DocumentRoot /www/NaszaDomenaZSsl
ServerName www.naszadomenazssl.pl
SSLEnable
SSLCACertificatePath /usr/local/apache-ssl/conf/ssl
SSLCACertificateFile /usr/local/apache-ssl/conf/ssl/cacert.pem
SSLCertificateFile /usr/local/apache-ssl/conf/ssl/newcert.pem
SSLCertificateKeyFile /usr/local/apache-ssl/conf/ssl/newreq.pem
...
</VirtualHost>

Jedyn

a znacz

a r´

o˙znic

a w konfiguracji serwer´

ow wirtualnych z SSL i bez

SSL na tym samym Apache’u jest dyrektywa SSLEnable/SSLDisable. To
w la´snie ta dyrektywa decyduje o tym, czy dany serwer wirtualny ma by´

obs lugiwany przez bezpieczny protok´

o l SSL, czy te˙z nie.

2.4

Tworzenie certyfikat´

Kiedy mamy ju˙z zainstalowanego Apache’a i OpenSSL’a nale˙zy przej´s´

c do

wygenerowania certyfikat´

ow niezb

ednych do dalszej pracy. Poni˙zej zostanie

przedstawiony spos´

ob generowania certyfikat´

ow przy u˙zyciu OpenSSL. Go-

towe skrypty u latwiaj

ace generowanie certyfikat´

ow znajduj

a si

e w katalogu

/usr/local/ssl/misc, a zatem wchodzimy to tego katalogu i zabieramy si

za generowanie certyfikat´

ow:

UWAGA: standardowo wa˙zno´s´

c wystawianego certyfikatu dla instytucji cer-

tyfikuj´

cej, jak i zwyk lego certyfikatu dla strony WWW to rok (365 dni),

czyli jak wystawimy sobie certyfikat dla naszej instytucji certyfikujacej, a
kilka minut p´

o´

zniej certyfikat dla jakie´s witryny WWW, to wa˙zno´s´

c cer-

tyfikatu dla witryny b

edzie przekracza´

c termin wa˙zno´sci certyfikatu insty-

tucji, kt´

ora b

edzie wystawia´

c ten certyfikat ...MSIE wyrzuci wykrzyknik,

˙ze mu to nie odpowiada.

Aby temu zapobiec - nale˙zy wyedytowa´

c plik

/usr/loca/ssl/misc/CA.sh i poprawi´

c lini

e nr 87. Jest tam:

-out $CATOP/$CACERT $DAYS
i zmieni´

c to na :

-out $CATOP/$CACERT -days 1024
wtedy certyfikat wystawiany dla instytucji certyfikuj

acej b

edzie mia l wa˙zno´s´

oko lo 4 lata, a wa˙zno´s´

c certyfikat´

ow dla witryn pozostaje bez zmian - 1 rok.

... i ju˙z MSIE nie wyrzuca l komunikat´

ow o b l

edzie.

Tworzymy certyfikat dla instytucji certyfikuj

acej, kt´

orym to certyfikatem

edzie mo˙zna podpisywa´

c certyfikaty dla witryn. Wydajemy polecenie:

./CA.sh -newca
Skrypt zapyta si

e o nazw

e pliku, w kt´

orym ma utworzy´

c certyfikat (je´sli

naci´sniemy enter zostanie nadana nazwa domy´slna).
Generowany jest 1024 bitowy klucz prywatny szyfrowany algorytmem RSA.
Nast

epnie musimy poda´

c has lo, kt´

orym nasz certyfikat b

edzie opatrzony.

Po´

zniej podajemy kilka danych, kt´

ore b

a zapisane w certyfikacie. Te dane

to:

1. Country, czyli dwuliterowy kod kraju, dla Polski PL.

2. State or Province Name, czyli nazwa stanu lub prowincji, jest to dana

tekstowa informacyjna, np. Mazowsze.

3. Locality Name, czyli lokalizacja CA, np. Warszawa.

4. Organization Name, czyli nazwa organizacji, koncernu, firmy, np. Trot-

nik Corp.

5. Organizational Unit Name, czyli nazwa dzia lu, np. CA.

6. Common Name, czyli adres www naszego CA, np. l10.iem.pw.edu.pl.

7. Email Address, czyli adres poczty elektronicznej, np. sierocim@ee.pw.edu.pl.

Po zako´

nczeniu dzia lania skryptu zostanie utworzony katalog ./demoCA

oraz kilka plik´

ow i podkatalog´

ow. Nas b

a interesowa tylko pliki:

./demoCA/cacert.pem - certyfikat naszej instytucji certyfikuj

acej

./demoCA/private/cakey.pem - klucz prywatny powyszego certyfikatu

Tworzymy nast

epnie certyfikat dla witryny internetowej (dla ka˙zdej wit-

ryny SSL-owej generuje si

e osobny certyfikat, poniewa˙z nazwa zawarta w

certyfikacie musi si

e zgadza´

c z nazw

a domenow

a strony internetowej, dla

kt´

orej tworzymy certyfikat. W przeciwnym wypadku przegl

arka internetowa

wyrzuci wykrzyknik przy wej´sciu na tak

a stron

e, ˙ze ’Nazwa zawarta w cer-

tyfikacie nie zgadza si

e z nazw

a strony’. Wydajemy polecenie:

$./CA.sh -newreq
podajemy has lo, jakie chcemy mie´

c dla wygenerowanego klucza prywatnego,

oraz kilka danych na temat certyfikatu(tak jak poprzednio).

Uwaga: Wa˙zne jest, aby przy Common Name (eg, Your Name) []: poda´

nazw

e domenow

a strony, dla kt´

orej jest tworzony certyfikat, w przeciwynym

wypadku przegl

adarmka MSIE wyrzuci wy˙zej wspomniany wykrzyknik.

Zostanie utworzony plik ./newreq.pem, kt´

ory trzeba ”podpisa´

c”w insty-

tucji certyfikuj

acej. Instytucji takich jest ”kilka´

na Internecie, ale za pod-

pisanie takiego certyfikatu p laci si

e oko l o 125 USD. Ale nie zawsze jest

potrzeba posiadania certyfikatu wystawionego przez tak

a firm

e, dlatego te˙z

mo˙zemy sami sobie podpisa´

c sw´

oj certyfikat. Po to wa´snie wcz

esniej ut-

worzyli´smy certyfikat instytucji certyfikuj

acej.

ec podpisujemy nasz nowy certyfikat w (naszej) instytucji certyfikuj

acej

wydaj

ac polecenia:

$./CA.sh -sign
Skrypt poprosi nas teraz o has lo do klucza prywatnego instytucji certy-
fikuj

acej, nast

epnie dwa razy potwierdzamy ”y”i dostajemy podpisany certy-

fikat dla naszej strony WWW. S

a nimi dwa pliki: ./newcert.pem - certyfikat

dla strony internetowej i ./newreq.pem - klucz prywatny dla powy˙zszego cer-
tyfikatu.

Jeszcze tylko pomocne (opcjonalnie) mo˙ze by´

c usuni

ecie has la z klucza

prywatnego naszego certyfikatu, gdy˙z wtedy unikniemy pytania o has lo przy
starcie apache-ssl’a. Has lo z klucza prywatnego usuwa si

e wydaj

ac polece-

nie:
$openssl rsa -in newreq.pem -out newreq.pem
Czyli mamy 4 pliki, kt´

ore nas interesuj

a z ca lego katalogu ./demoCA:

./demoCA/cacert.pem - certyfikat naszej instytucji certyfikujacej
./demoCA/private/cakey.pem - klucz prywatny naszej instytucji certyfikuj

acej

./newcert.pem - certyfikat dla witryny internetowej
./newreq.pem - klucz prywatny certyfikatu dla naszej witryny.

2.5

Przyk ladowe certyfikaty

Je li mamy ju˙z wygenerowane certyfikaty mo˙zemy je obejrze´

c.I tak np.klucz

prywatny certyfikatu dla naszej witryny (zapisany w pliku newreq.pem )
wygl

ada nast

epuj

aco:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,388425BD3C4A1A20

TBj3nlS266BvZti3pgLSPEwE/uhYFTPa6ImxejhsJGyJcpDl1piFq/qdfagZY2+a
SgW8kBPQM3wP64/+5IRuPGezXbNVY7J4dNPjMcoq3Y+RWij+FsyeXP2ckF5DudEH
CvWCttK6xJC1aq+HwwD+JFpisrqLYjLCMvuxgOtOX4u/lfo7mD9iFOHd1sJpLhH1
v8VBxgdFpWFsD9LT5XDYTSJGgQgbqH3iKLhhHqntTv0qFzlSvNdq23k0u9mh2M85
s0jkSCqEJp3wr3TUk9ll3XOcPwYJ2r338QB+kI2DtzpZVgXxrQgOTitxu6aYeGIN
nlW5hAuzzQNBN7V6xKNSwRSb0XeKUZFSIkf/mTkR5ojfaGblfh5JTgnSu0/cWTMq

lIHUgkEMV8FBcO4F3ZVvkLSUMEGy/rx6jJXj8OSbLND8Gcg5cpKkd7wOocF/2FO7
Aw61WEfVGy/03/3sTxaUsBhOGUJaoYQi+PREmB2TS39BbFsRvkAp+5BhCbsz34CV
Z+TcCyGDSpUN55bUHrmZnBHar1SsnBeBxkna4KMDu6uHOm8Ows116wvqTgG+Z8iC
yHb1UGZj8W8Z5xtOj91ZvB585akBfacvf22im6WRCmqjuyukRwvQvZYppKHMezO8
RJTKUTNgpEWdx+yncVDmMtasd01/AwwM1t/EOkpEyxk96vtLdwxNR/FV+EAN5xKT
QgPvANhuILIZniSr5sFh1BsqdvmyNZa5rDeZ5hDnEKI75SpUv0LZI5lKH17CO/gm
RFo3lNphsMbwmIzozFSxLXSq35jnhO9nuA9p78O7T06ZoarSCom/7w==
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE REQUEST-----
MIIBxjCCAS8CAQAwgYUxCzAJBgNVBAYTAnBsMREwDwYDVQQIEwh3YXJzemF3YTEM
MAoGA1UEBxMDc2FzMQ0wCwYDVQQKEwRhc2FzMQwwCgYDVQQLEwNzYXMxFDASBgNV
BAMTCzE5Mi4xNjguMS45MSIwIAYJKoZIhvcNAQkBFhN0cm90bmlrQDE5Mi4xNjgu
MS45MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDM4/FVRutrZpbvlZy1R/Ke
/4Og2CErDrtU3xT3BUPDl4nWVabqeEkLXzqFw+wVbFFEnvrcl2nlFSoT+sxVtAS+
PEEiRakEBew7Hs8r0GHk/lMaiPEWqpOChqdYEGFhXrVsHEizh1D6TC0oqaWYg1Tl
uskvmST2J9xSJqTWCX7AuwIDAQABoAAwDQYJKoZIhvcNAQEEBQADgYEAb5TMULCp
GKsL2xDNjEp1Rtm+Y9Cg+Dx7J+3kFR5sw6L/sCXacLY+E6K4EsXOUr5+i0tzRXZy
O+7YM7RaqxxDeANR+U9rCJHPH+KpkiaoXqnxVFOFEdsw/mgrPYTaWZYEY1yRowyd
mqqjiUIonx/g8BFfAbHrwkkekEwDxMzvkRQ=
-----END CERTIFICATE REQUEST-----

Certyfikat naszej instytucji certyfikuj

acej przedstawia si

e nast

epuj

aco :

Komend

/usr/local/ssl/bin/openssl x509 -in newcert.pem -noout -text

mo˙zna otrzyma´

c nast

epuj

acy wydruk przedstawiaj

acy w czytelny spos´

ob za-

warto´s´

c certyfikatu X.509:

Certificate:

Data:

Version: 3 (0x2)
Serial Number: 0 (0x0)
Signature Algorithm: md5WithRSAEncryption
Issuer: C=PL, ST=Mazowsze, L=Warszawa, O=Trotnik Corp,
OU=CA, CN=l10.iem.pw.edu.pl/Email=sierocim@ee.pw.edu.pl
Validity

Not Before: Jan 14 01:34:46 2002 GMT
Not After : Jan 14 01:34:46 2003 GMT

Subject: C=PL, ST=Mazowsze, L=Warszawa, O=Trotnik Corp,
OU=CA,CN=l10.iem.pw.edu.pl/Email=sierocim@ee.pw.edu.pl
Subject Public Key Info:

Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)

Modulus (1024 bit):

00:c4:6c:87:33:e0:10:c1:4e:a7:29:cd:0f:80:f1:
1c:da:2d:a7:2c:05:fe:db:4e:ef:a6:0a:06:79:7b:
ad:c2:25:4c:4b:3b:be:52:bd:da:be:05:2c:cd:4f:
f0:1e:96:d9:4a:07:3b:c0:19:ce:f9:6c:5d:39:4d:
8f:b7:a6:11:ca:a1:b7:d5:15:d6:e3:77:d3:ef:64:
09:fd:ab:f6:4f:1a:81:ac:e6:db:cb:ec:b1:04:34:
42:23:6e:58:85:69:cf:3e:3e:a4:89:9b:4c:08:87:
78:2b:5f:61:15:25:88:ca:a0:ce:3b:62:c9:42:dd:
79:c2:f9:ed:63:0d:45:48:d1

Exponent: 65537 (0x10001)

X509v3 extensions:
X509v3 Subject Key Identifier:
B9:C9:29:9C:92:AB:66:95:A6:BD:3C:6A:7C:A8:81:28:B4:36:E2:11
X509v3 Authority Key Identifier:
keyid:B9:C9:29:9C:92:AB:66:95:A6:BD:3C:6A:7C:A8:81:28:B4:36:E2:11
DirName:/C=PL/ST=Mazowsze/L=Warszawa/O=Trotnik Corp/OU=CA/
CN=l10.iem.pw.edu.pl/Email=sierocim@ee.pw.edu.pl
serial:00

X509v3 Basic Constraints:

CA:TRUE

Signature Algorithm: md5WithRSAEncryption

24:1a:75:b1:8d:e1:24:bf:eb:84:ce:76:c4:ff:d2:03:4a:d6:
2a:c6:59:e1:f4:57:2e:01:d5:85:58:fa:0b:6d:65:7c:17:b4:
46:56:ff:d7:41:2a:e2:f5:56:3e:93:40:f3:9a:25:42:4f:8e:

9d:f8:8d:5e:4a:8c:14:01:7f:44:24:fc:87:80:4f:34:16:ed:
98:10:9d:24:0e:10:73:e3:e1:06:3e:88:b8:7e:95:c1:d1:74:
1b:37:cf:16:1c:b4:c1:90:a7:4f:97:c1:e7:f5:08:1c:e4:c6:
62:d6:ff:f4:f2:db:6b:0f:ca:2b:b2:30:e1:95:5a:1c:16:ca:
95:2d

2.6

Przyk ladowa konfiguracja

Podstawowej konfiguracji serwera Apache dokonuje si

e w pliku httpsd.conf.

W nowszych wersjach zrezygnowano z umieszczania konfiguracji dost

epu

w pliku access.conf i konfiguracji zasob´

ow w pliku srm.conf, przenosz

ac ich

zawarto´s´

c do pliku httpsd.conf. Jedynie plik mime.types, okre´slaj

acy sko-

jarzenia rozszerze´

n plik´

ow z typami MIME (Multipurpose Internet Mail Ex-

tension), ze wzgl

edu na swoj

a wielko´s´

c pozostawiono osobno.

Przedstawienie pe lnej konfiguracji serwera Apache jest tematem niejednej
ksi

a˙zki i wykracza poza temat tej pracy. Postanowi lem przedstawi´

c tylko

podstawow

a konfiguracj

e oraz proponowane zmiany w konfiguracji serwera

zwi

azane z wprowadzeniem obs lugi wywo la´

n HTTPS.

Prace na pliku httpsd.conf nale˙zy przeprowadzi´

c przed pierwszym uruchomie-

niem serwera. Minimalna zmiana jak

a nale˙zy zawsze wprowadzi´

c dotyczy

dyrektywy

ServerName l10.iem.pw.edu.pl

po kt´

orej nale˙zy poda´

c domen

e pod jak

a b

edzie pracowa l serwer.Po´

zniej

musimy okre´sli´

c katalog zawieraj

acy dokumenty serwera WWW np.

DocumentRoot /usr/local/www .
Opcje Alias i ScriptAlias odwzorowuj

a ´scie˙zk

e URL na katalog w serw-

erze. Na przyk lad:
ScriptAlias /cgi-bin/ /usr/local/www/cgi-bin/

Polecenie ScriptAlias dzia la wten spos´

ob co zwyk ly Alias tylko, ˙ze wskazy-

wany katalog zawiera wykonywalne programy CGI. Httpsd nadaje temu kata-
logowi przywileje wykonywalne. ScriptAlias pozwala przechowywa´

c wykony-

walne skrypty w katalogu innym ni˙z DocumentRoot. Skrypty CGI stanowi

wielkie zagro˙zenie bezpiecze´

nstwa serwera a przechowywanie ich w oddziel-

nym katalogu pozwala na ´sci´slejsz

a ich kontrol

W pliku konfiguracyjnym serwera musimy oczywi´scie umie´sci´

c dyrektywy

zwi

azane z obs lug

a SSL.W pliku tym musz

a si

e oczywi´scie znajdowa´

c omaw-

iane wcze´sniej dyrektywy.Dodatkowo mo˙zemy doda´

SSLRequireSSL dyrektywa ta wymusza u˙zycie protoko lu SSL i mo˙ze by´

umieszczona np. wsekcji <Directory> pliku konfiguracji serwera. Pozwala
ona zabezbieczy´

c si

e przed skutkami pomy lkowego zablokowania u˙zycia

szyfrowania SSL i wynikaj

acego st

ad udost

epnienia danych, kto˙ze powinny

by´

c utajnione.Nieszyfrowane odwo lania do danych znajduj

acych si

e w

zakresie dzia lania tej dyrektywy b

a odrzucane.

SSLSessionCacheTimeout (czas) - nawi

azanie pierwszego po l

aczenia pomi

edzy

klientem a serwerm wi

a˙ze si

e z wygenerowaniem jednorazowego klucza

sesji.Warto´s´

c parametru tej dyrektywy okre´sla czas w sekundach przez

jaki ten klucz b

edzie przechowywany w lokalnym buforze. Im mniejszy

ten czas tym potencjalny w lamywacz ma mniej czasu na rozszyfrowanie
tego klucza. Jednocze´snie ustawienie kr´

otkiego czasu wymusza cz

este

generowanie kluczy co spowalnia transmisj

e danych.

SSLVerifyClient (0-3) dyrektywa ta ustala zakres informacji uwierzytel-

niaj

acych ˙z

adanych od klienta:0-certywikat w og´

ole nie jest wymagany,1-

klient mo˙ze przedstawi´

c wa˙zny certyfikat, 2-klient musi przedstawi´

wa˙zny certyfikat,3-klient mo˙ze przedstawi´

c wa˙zny certyfikat, jednak

certyfikat ten mo˙z pochodzi´

c z urz

edu certyfikacji nieznanego serwerowi.

SSLVerifyDepth (g l

eboko´

s´

c) -dyrektywa ta okre´sla liczb

e poziom´

ow hi-

erarchi urz

ed´

ow certyfikacji, kt´

ore serwer powinien przebada´

c w celu

uwierzytelnienia klienta.

SSLLogLevel (poziom) - dyrektywa ta okre´sla poziom od kt´

orego komu-

nikaty maj

a by´

c zapisywane w logu (none, error, warn, info, trace lub

debug)

SSLCARevocationFile (plik) -dyrektywa ta okre´sla plik zawieraj

acy list

certyfikat´

ow do odrzucenia pomimo wa˙zno´sci dat

SSLCARevocationPath (´

scie ˙zka) - dyrektywa ta okre´sla katalog zaw-

ieraj

acy list

e certyfikat´

ow do odrzucenia pomimo wa˙zno´sci dat

SSLCipherSiute (szyfry) -dopuszczalne szyfry (np.RSA:RC4:DES:MD5 )

Konfiguruj

ac serwer Apache’a trzeba r´

ownie˙z okre´sli´

c kontrol

e dost

epu na

poziome katalogu.Jak wiadomo Apache okre´sla dost

ep hierarchicznie tzn.

je´sli jaki´s katalog ma du˙ze uprawniwnia co do wykonywania w nim operacji
to i wszystkie jego podkatalogi przejmuj

a te uprawnienia.Je´sli zezwolimy np.

na wykonywanie skrypt´

ow w katalogu /usr/local/www to skrypty b

edziemy

mogli wykonywa´

c r´

ownie˙z we wszystkich podkatalogach wymienionego kat-

alogu. Mo˙zemy to wy l

aczy´

c ale gdy o tym zapomnimy b

edzie to stanowi´

ogromn

a luk

e w systemie bezpiecze´

nstwa naszego systemu. Dlatego katalogi

powinny mie´

c jak najmniejsze uprawnienia, kt´

ore w miar

e potrzeb mo˙zemy

zwi

ekszy´

c w konkrektnych podkatalogach.Dyrektywa AccessFileName .htaccess

acza kontrol

e dost

epu na poziomie katalogu. Nazw

a pliku dost

epu jest

.htaccess.Je˙zeli serwer znajdzie plik o takiej nazwie w katalogu, z kt´

orego

uzyskuje informacj

e, przed przekazaniem danych stosuje ograniczenia dost

epu

zdefiiniowane w pliku.

Polecenia kontroli dost

epu w pliku .htaccess s

takie same jak te u˙zywane w httpsd.conf’ie.Mo˙zemmy np. umie´sci´

c tu

nast

epuj

acy wpis:

<Directory/>
Options None
AllowOverride None
</Directory>
<Directory /usr/local/www>
Options None
AllowOverride None
</Directory>
<Directory /usr/local/www.cgi-bin>
AllowOverrde None
Options ExecCGI
</Directory>
Etykiety sekcji Directory obejmuj

a polecenia, kt´

ore odnoasz

a si

e do okre´slonego

katalogu.W naszym przypadku mamy trzy sekcje. Polecenie Options, okre´sla
kt´

ore opcje serwera mog

a mog

a by´

c u˙zyte przez dokumenty w danym kata-

logu. Polecenie to mo˙ze mie´

c kilka warto´sci np.

• ALL -zezwala na u˙zycie wszystkich opcji serwera

• ExecCGI -zezwala na wykonywanie z katalogu skrypt´ow CGI

• Indexes -zezwala na generowanie listingu plik´ow gdy w katalogu nie

ma pliku index.html

• None -nie zezwala na ˙zadne opcje serwera

Polecenie AllowOverride dopuszcza wiele r´

o˙znych ustawie´

W naszym

przypadku zosta lo ona wywo lane z opcj

a ’None’ , kt´

ora nie pozwala na zmian

˙zadnego ustawienia przez plik .htaccess. Opcja ’ALL’ pozwala na dowolne

zmiany wprowadzane przez plik .htaccess.
Je´sli chemy aby dost

ep do naszej witryny by l mo˙zliwy tylko dla okre´slonych

u˙zytkownik´

ow za podaniem has la musimy w pliku httpsd.conf umie´sci´

nast

epuj

acy wpis:

<Directory /usr/local/apache-ssl/htdocs/manual>
AuthType Basic
AuthUserFile /usr/local/apachessl/bin/users
AuthGroupFile /usr/local/apache-ssl/bin/grupy
require valid-user
</Directory>
Dyrektywa AuthType okre´sla typ u˙zywanej techniki uwierzytelniania.
Dyrektywa AuthGroupFile okre´sla grupy u˙zykownik´

ow kt´

ore maj

a dost

do naszej strony.
DyrektywaAuthUserFile okre´sla ´scie˙zke do pliku, w kt´

ory zawarci s

a u˙zytkownicy

(i ich has la), kt´

orzy maj

a dost

ep do naszej witryny.Do dodawania nowych

u˙zykownik´

ow mog

acych korzysta´

c z naszej strony s lu˙zy polecenie htpasswd,

kt´

ore znajduje si

e w katalogu usr/local/apache-ssl/bin.

2.7

Efektywno´

s´

Por´

ownuj

ac serwer HTTP i HTTPS przes lali´smy 2 pliki:1 rz

edu kilkunastu

kilobajt´

ow i drugi o wielko´sci kilkunastu MB. Podczas pierwszego po laczenia

i ´sci

agniecia pliku ma lego w przypadku serwera HTTPS czeka si

e chwil

e(ok.2

sekund) dlu˙zej ni˙z w przypadku zwyk lego Apache’a.R´

oznica ta zanika je˙zeli

operacj

e powt´

orzymy kolejny raz. Zwi

azane jest to z buforowaniem kluczy

sesyjnych. W przypadku du˙zych plik´

ow istnieje r´

ownie˙z zauwa˙zalna r´

ornica,

egaj

aca nawet 30-40%. Wynika to z kodowania przesy lanych danych. Ni-

estety nie mieli´smy mo˙zliwo´sci zobaczenia jak to b

edzie wygl

ada lo przy pracy

na normalnym modemie.Mo˙zemy tylko wnioskowa´

c, ˙ze r´

o˙znic

e bedzie wida´

ale mniej ni˙z w przypadku stosunkowo szybkiej sieci, w kt´

orej przeprowadzili´smy

testy. Po l

aczenie modemowe jest powolne i bardzo wra˙zliwe na wszelkie za-

tory w sieci.