Kryptografia i Ochrona Danych
Instalacja i Konfiguracja
Apache-SSL
Autor: Pawe Dynarowski
Luty 2002
Spis treści
1 Wstep teoretyczny 2
1.1 Wprowadzenie . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Protokól HTTP i serwer Apache . . . . . . . . . . . . . . . . . 2
1.3 Identyfikacja i poufność danych . . . . . . . . . . . . . . . . . 3
1.4 Infrastruktura kluczy i certyfikaty cyfrowe . . . . . . . . . . . 4
1.5 Wiecej o protokole SSL . . . . . . . . . . . . . . . . . . . . . . 5
2 Apache realizujacy protokól HTTPS 6
2.1 Instalacja SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Instalacja nakladki Apache-SSL . . . . . . . . . . . . . . . . . 7
2.3 Konfiguracja Apache a do wspólpracy z SSL . . . . . . . . . . 8
2.3.1 Wspólpraca tylko z SSL . . . . . . . . . . . . . . . . . 8
2.3.2 Jednoczesna obsluga witryn z SSL i bez SSL . . . . . . 10
2.4 Tworzenie certyfikatów . . . . . . . . . . . . . . . . . . . . . . 11
2.5 Przykladowe certyfikaty . . . . . . . . . . . . . . . . . . . . . 13
2.6 Przykladowa konfiguracja . . . . . . . . . . . . . . . . . . . . 16
2.7 Efektywność . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1
1 Wstep teoretyczny
1.1 Wprowadzenie
Na poczatku pracy należy wspomnieć, że żaden dokument RFC nie określa
protokolu HTTPS. Protokolem HTTPS określamy normalny protokól HTTP
zabezbieczony protokolem SSL. Protokól HTTP ( HyperText Transfer Pro-
tocol) sluży do porozumiewania sie pomiedzy klientami i serwerami sieci
WWW. Natomiast SSL (Secure Socket Layer) jest protokolem ogólnego przez-
naczenia wykorzystywanym do przesylania zaszyfrowanych informacji za po-
moca internetu . Podstawowym wymaganiem, które należy spalnić w celu
skutecznego wykorzystania ktyptografii klucza publicznego w komunikacji in-
ternetowej, jest ujednolicenie mechanizmów kryptograficznych używanych w
serwerach WWW i przegladarkach. Ton calej dyskusji nadala już jakiś czas
temu firma Netscape Communications, wprowadzajac protokól szyfrujacy
SSL, wykorzystujacy algorytmy szyfrowania asymetrycznego i w chwili obec-
nej wyznaczajacy standard wśród aplikacji zawiazanych z WWW. Z pro-
tokolem SSL konkurowalo kilka innych rozwiazań, miedzy innymi niezbyt
rozpowszechniony protokól SHTTP (Secure HyperText Transfer Protocol)
i opracowany przez zespól IRTF (Internet Engineering Task Force) pro-
tokól TLS (Transport Layer Security), który mial zastapić SSL. Prace nad
protokolem TLS jednak ostatecznie przerwano i na polu bezpiecznych pro-
tokolów internetowych pozostal jedynie używany dziś powszechnie protokól
SSL.
1.2 Protokól HTTP i serwer Apache
Wszystkie transakcje HTTP budowane sa na podstawie tego samego zasad-
niczego schematu wsklad którego wchodza: zapytanie(ze strony klienta) lub
status odpowiedzi (ze strony serwera), naglówek - kończacy sie pusta linia -
oraz treść.
Klient HTTP (przegladarka internetowa, np. Netscape Navigator lub Mi-
crosoft Internet Explorer) laczy sie z serwerem HTTP (zwanym inczej ser-
werem WWW) na porcie o określonym numerze (domyślnie jest to port
80 ). Nastepnie klient wysyla zapytanie o dokument. Dokumentem może
być również program, którego wyniki należy zwrócić klientowi. Nastepnie
przesylany jest naglówek, zawierajacy opcjonalne informacje o konfiguracji
klienta oraz opcjonalne dane dodatkowe.
Serwer WWW wysyla odpowiedz
zawierajaca wersje protokolu, kod odpowiedzi
i jego opis (pierwsza linia odpowiedzi zwana linia stanu). Nastepnie przesyla
naglówek zawierajacy dane dotyczace serwera i przesylanego dokumentu (przede
2
wszystkim format daych), a nastepnie przesyla sam dokument, którym może
być również, jak już wspomniano, odpowiedz
programu, dzialajacego zgod-
nie z mechanizmem wspólnego interfejsu bramy (ang. Common Gateway
Interface, CGI).
Najpopularniejszym w chwili obecnej serwerem WWW jest Apache. Mial
on niezaprzeczalny wplyw na rozwój sieci WWW, przede wszystkim dzieki
temu, że jest calkowicie darmowy, latwodostepny, dość bezpieczny (dzieki
strukturze systemów operacyjnych rodziny Unix, dla której zostal stwor-
zony), szybki, udostepnia bardzo rozbudowany i latwo rozszerzalny wach-
larz formatów danych, a przede wszystkim stale sie rozwija. Apache oparty
zostal na kodzie i rozwiazaniach zastosowanych w programie opracowanym w
NCSA (National Center for Supercomputing Applications, USA), które jest
agenda rzadu Stanów Zjednoczonych.
Obecnie najnowsza wersja Apache a jest Apache-1.3.22. Co prawda spotkalem
sie juz z wersja Apache-2.0.28 ale byla to wersja alfa i ze wzgledu na ewen-
tualne bledy i dziury nie zaleca sie jej narazie instalować.
1.3 Identyfikacja i poufność danych
Sieć internetowa stworzyla czlowiekowi niesamowita możliwość pozostawania
anonimowym. Istnieja jednak sytuacje, w których wszyscy chcieliby mieć
pewność co do tożsamości osób, z którymi sie kontaktuja. Wiekszość takich
sytuacji dotyczy sfery finansowej.
We wspólczesnym świecie umowy miedzyludzkie opieraja sie na zaufaniu.
Dotyczy to chociażby wypożyczenia ksia żki z biblioteki (biblioteka ufa, że zwróce
ksia żke), zawierania umowy kredytu (bank ufa, że kredyt splace) czy placenia
karta kredytowa (sklep ufa, że bank zaplaci za towar z mojego konta). Zau-
fanie to opiera sie na prawnej ochronie stanowionej przez państwo (państwo
może ograniczyć moja wolność i zmusić mnie do wywiazania sie z umowy)
oraz na identyfikacji mnie, jako strony umowy. Bez pewnej identyfikacji nie
byloby możliwe określenie kto byl strona umowy.
Identyfikacja w świecie realnym opiera sie na trudnych do podrobienia
dokumentach wydawanych przez organy państwowe, na umieszczonych w
tych dokumentah zdjeciach, które powinno być bardzo trudno podmienić bez
zniszczenia dokumentu i na naszym wlasnorecznym podpisie. Jest to zespól
dobrze funkcjonujacych, sprawdzonych i ciagle rozwijanych rozwiazań, ale
pomimo tego zdarzaja sie dość czesto przestepstwa.
Internet postawil w tej dziedzinie nowe wyzwania. Umowy (jak chociażby
zaplata karta kredytowa) sa zawierane bez fizycznej obecności czlowieka.
Placac chcemy mieć pewność, że naprawde nasze pieniadze dotra do sklepu,
a nie do kogoś kto sie pod sklep ,,podszywa . Ponieważ do zaplaty wystar-
3
czy kilka cyfr (numer karty i jej data ważności) zależy nam by danych tych
nie poznal nikt poza osobami uprawnionymi. Niezbedne oprócz identyfikacji
okazalo sie szyfrowanie danych, i to jak najbardziej zaawansowane. Tak za-
awansowane, by przestepcy nie oplacalo sie inwestować w odszyfrowywanie
danych, a z drugiej strony z punktu widzenia państwa (szczególnie jego
slużb bezpieczeństwa), by jego slużby mogly odszyfrować dane np. obcych
wywiadów.
1.4 Infrastruktura kluczy i certyfikaty cyfrowe
Najbardziej popularne techniki identyfikacji stosowane w internecie wyko-
rzystuja systemy bazujace na haslach, na przedmiotach (np. tokeny wydawane
przez banki) lub na biometrykach (np. odciski palców). Za najlepsze ulep-
szenie tych systemów, dzialajace czesto nawet samodzielnie, uznaje sie tech-
nologie systemu podpisów cyfrowych tworzonych za pomoca pary kluczy:
prywatnego i publicznego. Przy pomocy klucza prywatnego, znanego tylko
wlaścicielowi, podpisuje on (np. dolaczajac go do danych lub szyfrujac
nim dane) wysylane dane. Odbiorca, który wcześniej otrzymal od nadawcy
jego klucz publiczny, za pomoca tego klucza publicznego odczytuje podpis
(lub dane gdy sa zaszyfrowane) i jeśli odszyfrowanie sie powiodlo może być
pewien, że . . . wiadomość wyslal posiadacz danego klucza prywatnego. Dany
klucz publiczny jest jedynym, którym wiadomość zaszyfrowana przy pomocy
odpowiadajacego mu klucza prywatnego można odszyfrować. Klucz pry-
watny powinien wiec być bardzo pilnie strzeżony, przechowywany w postaci
zaszyfrowanej, chroniony haslem. Pomimo tego, w standardowych rozwiazaniach
dla wykonania z jego pomoca szyfrowania, musi i tak być w chwili szyfrowania
odkodowany i przechowywany w pamieci komputera, co szczególnie naraża
go na przejecie. Najbardziej zaawansowane w tej chwili rozwiazania pole-
gaja na przechowywaniu par kluczy na karcie elektronicznej z mikroproce-
sorem, która otrzymuje wiadomości i dokonuje na nich operacji. Jest to wiec
sprzetowa implementacja tej technologii, a jej bezpieczeństwo zależy od fizy-
cznego zabezpieczenia urzadzenia.
Kolejnym wyzwaniem bylo zapewnienie, że osoba lub firma identyfikujaca
sie dana para kluczy, to naprawde ta osoba. W tym celu powstaly urzedy
certyfikacji (ang. Certification Authority, CA). Za pomoca swoich kluczy pry-
watnych CA podpisuja klucze publiczne sprawdzonych przez siebie w świecie
rzeczywstych firm lub osób. Najbardziej znane CA to GTE Cyber Trust,
TC Trust Center, Thawte i Verisign (dawne RSA - firma zalożona przez
póz
niejszych profesorów MIT (Massachusetts Institute of Technology) - Ronalda
Rivesa, Adi Shamira i Leonarda Adlemana, autorów jednego z najpopu-
larniejszych algorytmów kryptograficznych opartych na parze kluczy - algo-
4
rytmu RSA). Każda taka firma wydaje oficjalny dokument ,,Zalożenia poli-
tyki certyfikacji (ang. Certification Practises Statement, CPS), opisujacy
metody przyznawania i cofania certyfikatów.
Podstawowym standardem certyfikatu, rekomendowanym przez Miedzynarodowa
Unie Telekomunikacyjna (ang. International Telecommunication Union, ITU-
T ), wykorzystywanym w protokole SSL jest X.509 v3. Sklada sie on z numeru
wersji, numeru seryjnego, danych identyfikacyjnych, informacji o stosowanym
algorytmie, danych podpisujacego i podpisywanego, daty wydania i terminu
ważności. W formie zakodowanej jest on przechowywany jako pilk tekstowy
w formacie określonym jako PEM.
1.5 Wiecej o protokole SSL
Protokól SSL tworzy warstwe rozdzielajaca podstawowy protokól TCP/IP
- odpowiedzialny za tworzenie polaczeń, przesylanie anonimowych strumieni
informacji i obslugujacy bledy - oraz warstwe aplikacji. Może także pracować
z innymi protokolami warstwy transportowej jeśli zapewniaja wysoka nieza-
wodność. Choć SSL zostal zaprojektowany do zabezpieczenia protokolu http,
istnieja już rozwiazania zabezpieczajace protokoly smtp , pop3.
SSL zapewnia:
" uwierzytelnianie i niezaprzeczalność serwera i klienta dzieki wykorzys-
taniu podpisów cyfrowych,
" poufność wymiany danych poprzez wykorzystanie szyfrowania,
" integralność danych dzieki wykorzystaniu kodów uwierzytelniajacych
wiadomości.
Do realizacji każdej z powyższych trzech ról wykorzystuje odrebne algorytmy,
które to wykorzystuja dodatkowo odrebne klucze, dzieki czemu restrykcje
wielu państw dotyczace technologii szyfrowania treści (np. Stany Zjednoc-
zone - zabroniony eksport najnowszych technologii, Francja - szyfrowanie
prawnie zabronione), nie ograniczaja bezpieczeństwa uwierzytelniania i iden-
tyfikacji.
OpensSSL jest najpopularniejsza darmowa implementacja SSL dla sys-
temów operacyjnych rodziny Unix, a jej jakość nie odbiega od produktów
komercyjnych. Bazuje na bibliotece SSLLeay. OpenSSL zostal stworzony
przez Ralfa Engelshalla z Wydzialu Elektrycznego Swiss Federal Institute of
Technology. Obsluguje protokoly SSLv2, SSLv3 i jego nastepna wersje TLS,
nad która prace ostatecznie zostaly zakończone. Z algorytmów szyfrujacych
5
wykorzystuje m.in DES, IDEA i Triple-DES. Obecnie najnowsza dostepna
wersja OpenSSL a jestOpenSSL-0.9.6c. Dostepna jest ona miedzy innymi
na stroniewww.apache-ssl.org.
2 Apache realizujacy protokól HTTPS
Aby serwer WWW (np. Apache) mógl korzystać z warstwy SSL (np. dzialajacej
dzieki bibliotece OpenSSL) niezbedne jest jego uzupelnienie o ,,lacznik . Jed-
nym z mażliwych rozszerzeń serwera Apache o możliwość realizowania pro-
tokolu SSL jest stworzony przez Bena Lauriego, jednego z twórców Apache a,
Apache-SSL. Narzedzie to wymaga rekompilacji serwera Apache o ile byl on
wcześniej zainstalowany. Wraz z wprowadzeniem do serwera Apache tech-
nologii modulów ladowalnych powstal w kwietniu 1998 modul mod ssl, au-
torstwa Ralfa S. Engelshalla, autora OpenSSLa. Wersja 2.0 opublikowana
w sierpniu 1998 nie byla już oparta na Apache-SSL u. Teoretycznie mod ssl
nie wymaga rekompilacji serwera apache. w praktyce jest troche inaczej,
poniważ mod ssl wymaga aby wcześniej Apache byl skompilowany z rozszer-
zonym interfejsem API zwanym EAPI, co w standardowej instalacji nie jest
wykonywane, wiec jeśli administrator nie przewidywal od poczatku potrzeby
instalacji mod ssl i tak wymagana jest rekompilacja Apache a).
W naszym przypadku do realizacji protokolu HTTPS użyliśmy Apache-
ssl(nie mylić z mod ssl co podkreśla sam producent na swojej stronie inter-
netowejwww.apache-ssl.org).
2.1 Instalacja SSL
Obecnie przedstawimy opis czynności majacych na celu stworzenie wersji ser-
wera apache obslugujacej wymiane danych w protokole HTTPS. Pierwszym
etapem bedzie zdobycie kodu bibliotekiOpenssl-0.9.6c. Można ja sciagnć
jak już wcześniej wspomnialem ze stronywww.apache-ssl.org. Najlepiej
żeby byla to wersja o której pisze ponieważ z wersjami nieco starszymi np.
Openssl-0.9.6b mialem problemy z ich kompilacja.Z niewiadomych do tej
pory przyczyn kompilator wyrzucal komunikaty o bledach i przerywal kom-
pilacje. W przypadku najnowszej wersji nie bylo najmniejszych problemów.
Instalacje biblioteki zaczynamy od skopiowania jej do odpowiedniego kat-
alogu np. do/usr/local/ssl/. Nastepnie należy ja rozpakować:
gzip -d openssl-0.9.6c
tar xvf openssl-0.9.6c
Efektem tego bylo pojawienie sie podkataloguopenssl-0.9.6czawierajacego
6
dość pokaz
na liczbe plików. Po przejściu do katalogu należ zapoznać sie z za-
wartościa plikuINSTALL, w którym jest opisany przebieg instalacjiOpenssl a.
Zgodnie z dokumentacja rozpoczecia procesu instalacji dokonuje sie poprzez
wydanie polecenia - ./Configure [nazwa systemu]. W naszym przypadku
mialo ono postać :
./Confugure FreeBSD
Nastepnie budujemy biblioteke wydajac polecenie :
make
spowoduje zbudowanie bibliotek OpenSSL(libcrypto.a i libssl.a) i niezbednych
programów. Biblioteki powinny zanjdować sie w katalogu glównym tzn.
/usr/local/ssl/a aplkikacje w katalogu/apps. Jeśli kompilacja zakończy
sie powodzeniem należy przetestować biblioteki ,wydajac polecenie :
make test
wynikiem ich wykonania jest multum wyświetlanych na ekranie informacji,
które dla przecietnego użykownika sa prawdopodobnie malo interesujace i
nieczytelne. Calość instalacji powinna zakończyć sie wydrukiem certyfikatu
tekstowego o nazwienewcert.pem. Ostatnim krokiem instalacji jest wydanie
polecenia :
make install
Po wykoniu tego polecenia biblioteka OpenSSL znajduje sie juz w katalogu
/usr/local/ssl/.
Alternatywa dlaOpenSSLmoże byćSSLeay-0.9.0b. Jest ona jednak
nieco starsza i trudniejsza w konfiguracji. Spelnia jednak taka sama role jak
omawiana bibliotekaOpenSSL-0.9.6c. Biblioteke ta można ściagna ć m.in z
ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL/.
2.2 Instalacja nakladki Apache-SSL
Do zainstalowania Apache a realizujacego protokól SSL oprócz opisanej wcześniej
bibliotekiOpenSSLniezbedne sa jeszcze dwa pliki : aktualna wersja serwera
Apache (w naszym przypadku jest toapache1.3.22oraz specjalny patch
do tego serwera -apache1.3.22+ssl1.44. Przy czym należy wspomnieć
o jednej bardzo ważnej rzeczy - omawiana nakladka powinna być jak na-
jnowsza ale musi odpowiadać posiadanej przez nas wersji serwera Apache, w
przeciwnym razie instalacja sie nie powiedzie.
Instalacje serwera Apache zaczynamy od usuniecia poprzedniej wersji ser-
wera na naszej maszynie - polecenie rm -R [katalog-apache]. Po ponownym
ropzakowaniu pliku .tar zawierajacego dystrybucje programu Apache i ut-
worzeniu odpowiedniego katalogu należy umieścić w nim patch, o którym
byla mowa wcześniej i rozpakować go :
tar -xzvffapache1.3.22+ssl1.44.tar.gz
7
otrzymujac w efekcie zestaw plików rozszerzeniem .SSL.
Zgodnie z opisem podanym w plikuREADME.SSLkolejnym krokiem jest
wykonanie polecenia:
./FixPatch
Na prośbe o potwierdzenie dokonania modyfikacji należy odpowiedzieć naciskajac
klawisz y.
W przypadku gdy nie uda nam sie zastosować patch a lub zwróci on nam
blad należy sparawdzić wersje posiadanego patcha (patch -version). Jeśli
jest on niższy od 2.1 to należy sciagnac nowszy, bo to on jest najbardziej
prawdopodobna przyczyna bledu.
Teraz możemy przystpić do kompilacji spatchowanego Apache a:
./configure
--prefix=/usr/local/apache-ssl
--enable-module=rewrite
--enable-shared=rewrite
make
make install
Jeśli wszystko sie udalo możemy przejść do konfiguracji serwera . Należy
tego dokonać przed pierwszym uruchomieniem serwera.
2.3 Konfiguracja Apache a do wspólpracy z SSL
2.3.1 Wspólpraca tylko z SSL
Poniżej opisze,ja skonfigurować Apache do wspólpracy TYLKO z SSL. Można
te skonfigurować go tak, aby obslugiwal witryny zarówno z SSL, jak i bez
SSL.
Domyślnie plik konfiguracyjny Apacha ma nazw httpsd.conf - niby
slusznie- ale twórcy serwera zapomnieli spaczować fragment Apacha, by ten
korzystal z pliku o takiej wlaśnie nazwie - Apache-SSL odwoluje sie do pliku
httpd.confprzy uruchomieniu ...którego nie ma.Wiec tworzymy link sym-
boliczny:
cd /usr/local/apahe-ssl/conf
ln -s httpsd.conf httpd.conf
i już Apache przy starcie nie bedzie krzyczal z tego powodu.
Żeby Apache-SSL prawidlowo wystartowal, należy w nim troche pozmieniać
i dopisać kilka rzeczy: - linijkePort 80iListen 80zmieniamy naPort 443
iListen 443, żeby nasluchiwal na standardowym dla protokolu https por-
cie.Należy jeszcze dopisać kilka dyrektyw niezbednych do obslugi SSL.Robimy
to w plikuhttpsd.confdodajac nastepujace linijki (obojetnie w którym
miejscu ale byle nie przed linia o treściAddModule apachessl.c):
8
Port 443 -mówi, że dana konfiguracja - w tym przypadku sekcji global -
dotyczy witryny obslugiwanej na porcie 443)
Listen 443 - nasluchiwanie serwera na porcie 443 - standardowy dla pro-
tokolu https)
SSLEnable (wlacza obsluge SSL)
SSLCACertificatePath /usr/local/apache-ssl/conf/ssl - ścieżka do kat-
alogu z certyfikatami
SSLCACertificateFile /usr/local/apache-ssl/conf/ssl/cacert.pem - cer-
tifikat instytucji, która wystawila 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ższego certyfikatu
SSLCacheServerPort 8080 - port gcache a
SSLCacheServerPath /usr/local/apache-ssl/bin/gcache - ścieżka do
programu gcache
SSLSessionCacheTimeout 10000 ( timeout )
Jeszcze przed uruchomieniem Apache a należy zgrać wygenerowane wcześniej
certyfikaty do katalogu/usr/local/apache-ssl/conf/ssl(katalog ten trzeba
wcześniej zalożyć).Należy skopiować te pliki do wymienionych katalogów:
/usr/local/openssl/ssl/misc/demoCA/cacert.pem
/usr/local/openssl/ssl/misc/newreq.pem
/usr/local/openssl/ssl/misc/newcert.pem
Żeby sprawdzić, czy w pliku konfiguracyjnym nie ma bledów, należy
urucjomić:
/usr/local/apache-ssl/bin/httpsdctl configtest.
Jeżeli wyskoczy napis  ok , możemy przystapić do uruchomienia Apache a
poleceniem:
/usr/local/apache-ssl/bin/httpsdctl start.
Aby sprawdzić czy serwer Apache zostal uruchomiony możemy wydać polece-
nie ps -aux, które wyświetla informacje o wszystkich aktywnych proce-
sach w systemie. Powinno sie tam znajdować 5 procesów o nazwiehttpsd.
Wlaścicielem pierwszego powinien być root a pozostalych użytkownik o
nazwiewwwnależacy do grupywww.Nie należy sie tym zbytnio przejmować,
9
ponieważ glówny proces należacy do roota w odróżnieniu od pozostalych nie
odbiera pojawiajacych sie w nim żadań, a musi on być on być wlaścicielem
tego procesu, gdzyż tylko on jest uprawniony do odwolywania sie do portów
o numerach mniejszych niż 1024.Zadaniem tego procesu jest zarzadzanie po-
zostalymi kopiami. W pliku konfiguracyjnym(httpsd.conf) musi też znaj-
dować sie odpowiedni wpis:
User www
Group www
Użytkownik ten nie może też mieć prawa wykonywania żadnych programów,
które nie sa przeznaczone do uruchomienia w odpowiedzi na żadania obslugiwane
przez program httpsd.Przed uruchomieniem serwera należy jeszcze określić
jego nazwe pod która bedzie widzoczny w sieci. Robimy to umieszczajac w
plikuhttpsd.confwpis:
ServerName nazwaserwer.domena
W tej chwili serwer jest gotowy do uruchomienia.
Teraz tylko za pomoca przegldarki wchodzimy na strone o adresie :
https://www.adres.naszej.strony.pl/.Jeśli przegladarka znajdzie nasza strone
i pojawi sie komunikat typu:  Za chwile obejrzysz strony w bezpiecznym
polaczeniu to znaczy, że instalacja przebiegla prawidlowo.
2.3.2 Jednoczesna obsluga witryn z SSL i bez SSL
Jednoczesna obsluge witryn z SSL i bez SSL można zrobić na 2 sposoby.
Można uruchomić dwa Apache y - jeden nasluchujacy na porcie 80 i serwujacy
witryny bez SSL, a drugiego uruchomić na porcie 443 i skonfigurować go
do serwowania witryn SSL. Sposobu konfiguracji w ten sposób chyba nie
trzeba opisywać. Zatem drugi sposób - odpalić jedna kopie Apache, który by
serwowal jednocześnie witryny z, jak i bez SSL. W tym przypadku kompilacja
odbywa sie tak samo, jak opisana powyżej do obslugi SSL. Jedyna niewielka
różnica bedzie konfiguracja serwera Apache. W pliku httpsd.conf w sekcji
global musi si znalez
ć nastepujacy wpis:
Listen 80
Listen 443
Port 80
co zmusi Apache a do nasluchiwania na porcie 80 i dodatkowo na 443 (wiecej
na ten temat w dokumentacji Apache), a Port 80 mówi mu, że konfiguracja
sekcji GLOBAL dotyczy portu 80.
Teraz możemy przystpić do konfiguracji serverów wirtualnych. Przykladowa
konfiguracja dwóch serwerów wirtualnyc (jeden z SSL, drugi bez) wyglada
nastepujaco:
NameVirtualHost 212.212.212.212:80
10
NameVirtualHost 212.212.212.212:443

DocumentRoot /www/NaszaDomenaBezSsl
ServerName www.NaszaDomenaBezSsl.pl
SSLDisable
...


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
...

Jedyna znaczaca różnica w konfiguracji serwerów wirtualnych z SSL i bez
SSL na tym samym Apache u jest dyrektywaSSLEnable/SSLDisable. To
wlaśnie ta dyrektywa decyduje o tym, czy dany serwer wirtualny ma być
obslugiwany przez bezpieczny protokól SSL, czy też nie.
2.4 Tworzenie certyfikatów
Kiedy mamy już zainstalowanego Apache a i OpenSSL a należy przejść do
wygenerowania certyfikatów niezbednych do dalszej pracy. Poniżej zostanie
przedstawiony sposób generowania certyfikatów przy użyciu OpenSSL. Go-
towe skrypty ulatwiajace generowanie certyfikatów znajduja sie w katalogu
/usr/local/ssl/misc, a zatem wchodzimy to tego katalogu i zabieramy sie
za generowanie certyfikatów:
UWAGA: standardowo ważność wystawianego certyfikatu dla instytucji cer-
tyfikujćej, jak i zwyklego certyfikatu dla strony WWW to rok (365 dni),
czyli jak wystawimy sobie certyfikat dla naszej instytucji certyfikujacej, a
kilka minut póz
niej certyfikat dla jakieś witryny WWW, to ważność cer-
tyfikatu dla witryny bedzie przekraczać termin ważności certyfikatu insty-
tucji, która bedzie wystawiać ten certyfikat ...MSIE wyrzuci wykrzyknik,
że mu to nie odpowiada. Aby temu zapobiec - należy wyedytować plik
/usr/loca/ssl/misc/CA.shi poprawić linie nr 87. Jest tam:
-out $CATOP/$CACERT $DAYS
i zmienić to na :
11
-out $CATOP/$CACERT -days 1024
wtedy certyfikat wystawiany dla instytucji certyfikujacej bedzie mial ważność
okolo 4 lata, a ważność certyfikatów dla witryn pozostaje bez zmian - 1 rok.
... i już MSIE nie wyrzucal komunikatów o bledzie.
Tworzymy certyfikat dla instytucji certyfikujacej, którym to certyfikatem
bedzie można podpisywać certyfikaty dla witryn. Wydajemy polecenie:
./CA.sh -newca
Skrypt zapyta sie o nazwe pliku, w którym ma utworzyć certyfikat (jeśli
naciśniemy enter zostanie nadana nazwa domyślna).
Generowany jest 1024 bitowy klucz prywatny szyfrowany algorytmem RSA.
Nastepnie musimy podać haslo, którym nasz certyfikat bedzie opatrzony.
Poz
niej podajemy kilka danych, które beda 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 dzialu, np. CA.
6. Common Name, czyli adres www naszego CA, np. l10.iem.pw.edu.pl.
7. Email Address, czyli adres poczty elektronicznej, np. [e-mail].
Po zakończeniu dzialania skryptu zostanie utworzony katalog ./demoCA
oraz kilka plików i podkatalogów. Nas beda interesowa tylko pliki:
./demoCA/cacert.pem - certyfikat naszej instytucji certyfikujacej
./demoCA/private/cakey.pem - klucz prywatny powyszego certyfikatu
Tworzymy nastepnie certyfikat dla witryny internetowej (dla każdej wit-
ryny SSL-owej generuje sie osobny certyfikat, ponieważ nazwa zawarta w
certyfikacie musi sie zgadzać z nazwa domenowa strony internetowej, dla
której tworzymy certyfikat. W przeciwnym wypadku przeglarka internetowa
wyrzuci wykrzyknik przy wejściu na taka strone, że  Nazwa zawarta w cer-
tyfikacie nie zgadza sie z nazwa strony . Wydajemy polecenie:
$./CA.sh -newreq
podajemy haslo, jakie chcemy mieć dla wygenerowanego klucza prywatnego,
oraz kilka danych na temat certyfikatu(tak jak poprzednio).
12
Uwaga: Ważne jest, aby przyCommon Name (eg, Your Name)[]: podać
nazwe domenowa strony, dla której jest tworzony certyfikat, w przeciwynym
wypadku przegladarmka MSIE wyrzuci wyżej wspomniany wykrzyknik.
Zostanie utworzony plik ./newreq.pem, który trzeba  podpisać w insty-
tucji certyfikujacej. Instytucji takich jest  kilkańa Internecie, ale za pod-
pisanie takiego certyfikatu placi sie okol o 125 USD. Ale nie zawsze jest
potrzeba posiadania certyfikatu wystawionego przez taka firme, dlatego też
możemy sami sobie podpisać swój certyfikat. Po to waśnie wczesniej ut-
worzyliśmy certyfikat instytucji certyfikujacej.
Wiec podpisujemy nasz nowy certyfikat w (naszej) instytucji certyfikujacej
wydajac polecenia:
$./CA.sh -sign
Skrypt poprosi nas teraz o haslo do klucza prywatnego instytucji certy-
fikujacej, nastepnie dwa razy potwierdzamy  y i dostajemy podpisany certy-
fikat dla naszej strony WWW. Sa nimi dwa pliki:./newcert.pem- certyfikat
dla strony internetowej i./newreq.pem- klucz prywatny dla powyższego cer-
tyfikatu.
Jeszcze tylko pomocne (opcjonalnie) może być usuniecie hasla z klucza
prywatnego naszego certyfikatu, gdyż wtedy unikniemy pytania o haslo przy
starcieapache-ssl a. Haslo z klucza prywatnego usuwa sie wydajac polece-
nie:
$openssl rsa -in newreq.pem -out newreq.pem
Czyli mamy 4 pliki, które nas interesuja z calego katalogu ./demoCA:
./demoCA/cacert.pem - certyfikat naszej instytucji certyfikujacej
./demoCA/private/cakey.pem - klucz prywatny naszej instytucji certyfikujacej
./newcert.pem - certyfikat dla witryny internetowej
./newreq.pem - klucz prywatny certyfikatu dla naszej witryny.
2.5 Przykladowe certyfikaty
Jeli mamy już wygenerowane certyfikaty możemy je obejrzeć.I tak np.klucz
prywatny certyfikatu dla naszej witryny (zapisany w pliku newreq.pem )
wyglada nastepujaco:
-----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
13
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 certyfikujacej przedstawia sie nastepujaco :
-----BEGIN CERTIFICATE-----
MIIDdDCCAt2gAwIBAgIBADANBgkqhkiG9w0BAQQFADCBiTELMAkGA1UEBhMCUEwx
ETAPBgNVBAgTCFdhcnN6YXdhMQ0wCwYDVQQHEwRjaXR5MRUwEwYDVQQKEwxUcm90
bmlrIGNvcnAxCzAJBgNVBAsTAnNjMRAwDgYDVQQDEwdUcm90bmlrMSIwIAYJKoZI
hvcNAQkBFhN0cm90bmlrQDE5Mi4xNjguMS45MB4XDTAyMDEwOTE5MzAyNFoXDTA0
MTAyOTE5MzAyNFowgYkxCzAJBgNVBAYTAlBMMREwDwYDVQQIEwhXYXJzemF3YTEN
MAsGA1UEBxMEY2l0eTEVMBMGA1UEChMMVHJvdG5payBjb3JwMQswCQYDVQQLEwJz
YzEQMA4GA1UEAxMHVHJvdG5pazEiMCAGCSqGSIb3DQEJARYTdHJvdG5pa0AxOTIu
MTY4LjEuOTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnE8pQPgZCN1Dh+eI
hTmoAdnVnLM59MS4GZFoNcb1Laj0z5EQAgspcZQqqhP4XR+p9kIvW73yGXSU62+f
qM2azPNCTM9/GqqErNgpep9LsOzRa/Fdtmk8/jSYE94U6lZGKWwP21aH1VfPUvmi
my+gpbvRzohVDXZhdZFmqFRjqtcCAwEAAaOB6TCB5jAdBgNVHQ4EFgQUojxAJSRV
8/vau/xxXGOz+BNHAMIwgbYGA1UdIwSBrjCBq4AUojxAJSRV8/vau/xxXGOz+BNH
AMKhgY+kgYwwgYkxCzAJBgNVBAYTAlBMMREwDwYDVQQIEwhXYXJzemF3YTENMAsG
A1UEBxMEY2l0eTEVMBMGA1UEChMMVHJvdG5payBjb3JwMQswCQYDVQQLEwJzYzEQ
MA4GA1UEAxMHVHJvdG5pazEiMCAGCSqGSIb3DQEJARYTdHJvdG5pa0AxOTIuMTY4
LjEuOYIBADAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAHjPhM2Rd90a
idYb0NmucaQli5Z8aGXXEKC4UYB6g7PBMxJyIcko/W21vleU0zSh0rquGGNiJeGv
GDfUO8LrTMEV5gPIHHPsNaDEWRd69XrB3OH65MYOhTi47CBm0mjC5vpEsHyFlDbS
ZnX3eZXA/Gtqz21A2o5cC+Ysw/9BXn8/
-----END CERTIFICATE-----
Komenda
/usr/local/ssl/bin/openssl x509 -in newcert.pem -noout -text
14
można otrzymać nastepujacy wydruk przedstawiajacy w czytelny sposób za-
wartość 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=[e-mail]
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=[e-mail]
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=[e-mail]
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:
15
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 Przykladowa konfiguracja
Podstawowej konfiguracji serwera Apache dokonuje sie w pliku httpsd.conf.
W nowszych wersjach zrezygnowano z umieszczania konfiguracji dostepu
w pliku access.conf i konfiguracji zasobów w pliku srm.conf, przenoszac ich
zawartość do pliku httpsd.conf. Jedynie plik mime.types, określajacy sko-
jarzenia rozszerzeń plików z typami MIME (Multipurpose Internet Mail Ex-
tension), ze wzgledu na swoja wielkość pozostawiono osobno.
Przedstawienie pelnej konfiguracji serwera Apache jest tematem niejednej
ksia żki i wykracza poza temat tej pracy. Postanowilem przedstawić tylko
podstawowa konfiguracje oraz proponowane zmiany w konfiguracji serwera
zwiazane z wprowadzeniem obslugi wywolań HTTPS.
Prace na pliku httpsd.conf należy przeprowadzić przed pierwszym uruchomie-
niem serwera. Minimalna zmiana jaka należy zawsze wprowadzić dotyczy
dyrektywy
ServerName l10.iem.pw.edu.pl
po której należy podać domene pod jaka bedzie pracowal serwer.Poz
niej
musimy określić katalog zawierajacy dokumenty serwera WWW np.
DocumentRoot /usr/local/www.
OpcjeAlias i ScriptAliasodwzorowuja ścieżke URL na katalog w serw-
erze. Na przyklad:
ScriptAlias /cgi-bin/ /usr/local/www/cgi-bin/
Polecenie ScriptAlias dziala wten sposób co zwykly Alias tylko, że wskazy-
wany katalog zawiera wykonywalne programy CGI. Httpsd nadaje temu kata-
logowi przywileje wykonywalne. ScriptAlias pozwala przechowywać wykony-
walne skrypty w katalogu innym niżDocumentRoot. Skrypty CGI stanowia
wielkie zagrożenie bezpieczeństwa serwera a przechowywanie ich w oddziel-
nym katalogu pozwala na ściślejsza ich kontrole.
W pliku konfiguracyjnym serwera musimy oczywiście umieścić dyrektywy
zwiazane z obsluga SSL.W pliku tym musza sie oczywiście znajdować omaw-
iane wcześniej dyrektywy.Dodatkowo możemy dodać:
16
SSLRequireSSL dyrektywa ta wymusza użycie protokolu SSL i może być
umieszczona np. wsekcjipliku konfiguracji serwera. Pozwala
ona zabezbieczyć sie przed skutkami pomylkowego zablokowania użycia
szyfrowania SSL i wynikajacego stad udostepnienia danych, ktoże powinny
być utajnione.Nieszyfrowane odwolania do danych znajdujacych sie w
zakresie dzialania tej dyrektywy beda odrzucane.
SSLSessionCacheTimeout (czas) - nawiazanie pierwszego polaczenia pomiedzy
klientem a serwerm wia że sie z wygenerowaniem jednorazowego klucza
sesji.Wartość parametru tej dyrektywy określa czas w sekundach przez
jaki ten klucz bedzie przechowywany w lokalnym buforze. Im mniejszy
ten czas tym potencjalny wlamywacz ma mniej czasu na rozszyfrowanie
tego klucza. Jednocześnie ustawienie krótkiego czasu wymusza czeste
generowanie kluczy co spowalnia transmisje danych.
SSLVerifyClient (0-3) dyrektywa ta ustala zakres informacji uwierzytel-
niajacych żadanych od klienta:0-certywikat w ogóle nie jest wymagany,1-
klient może przedstawić ważny certyfikat, 2-klient musi przedstawić
ważny certyfikat,3-klient może przedstawić ważny certyfikat, jednak
certyfikat ten moż pochodzić z urzedu certyfikacji nieznanego serwerowi.
SSLVerifyDepth (glebokość) -dyrektywa ta określa liczbe poziomów hi-
erarchi urzedów certyfikacji, które serwer powinien przebadać w celu
uwierzytelnienia klienta.
SSLLogLevel (poziom) - dyrektywa ta określa poziom od którego komu-
nikaty maja być zapisywane w logu (none, error, warn, info, trace lub
debug)
SSLCARevocationFile (plik) -dyrektywa ta określa plik zawierajacy liste
certyfikatów do odrzucenia pomimo ważności dat
SSLCARevocationPath (ścieżka) - dyrektywa ta określa katalog zaw-
ierajacy liste certyfikatów do odrzucenia pomimo ważności dat
SSLCipherSiute (szyfry) -dopuszczalne szyfry (np.RSA:RC4:DES:MD5 )
Konfigurujac serwer Apache a trzeba również określić kontrole dostepu na
poziome katalogu.Jak wiadomo Apache określa dostep hierarchicznie tzn.
jeśli jakiś katalog ma duże uprawniwnia co do wykonywania w nim operacji
to i wszystkie jego podkatalogi przejmuja te uprawnienia.Jeśli zezwolimy np.
na wykonywanie skryptów w katalogu/usr/local/wwwto skrypty bedziemy
17
mogli wykonywać również we wszystkich podkatalogach wymienionego kat-
alogu. Możemy to wylaczyć ale gdy o tym zapomnimy bedzie to stanowić
ogromna luke w systemie bezpieczeństwa naszego systemu. Dlatego katalogi
powinny mieć jak najmniejsze uprawnienia, które w miare potrzeb możemy
zwiekszyć w konkrektnych podkatalogach.DyrektywaAccessFileName .htaccess
wlacza kontrole dostepu na poziomie katalogu. Nazwa pliku dostepu jest
.htaccess.Jeżeli serwer znajdzie plik o takiej nazwie w katalogu, z którego
uzyskuje informacje, przed przekazaniem danych stosuje ograniczenia dostepu
zdefiiniowane w pliku. Polecenia kontroli dostepu w pliku.htaccesssa
takie same jak te używane whttpsd.conf ie.Możemmy np. umieścić tu
nastepujacy wpis:

Options None
AllowOverride None


Options None
AllowOverride None


AllowOverrde None
Options ExecCGI

Etykiety sekcjiDirectoryobejmuja polecenia, które odnoasza sie do określonego
katalogu.W naszym przypadku mamy trzy sekcje. PolecenieOptions, określa
które opcje serwera moga moga być użyte przez dokumenty w danym kata-
logu. Polecenie to może mieć kilka wartości np.
" ALL-zezwala na użycie wszystkich opcji serwera
" ExecCGI-zezwala na wykonywanie z katalogu skryptów CGI
" Indexes-zezwala na generowanie listingu plików gdy w katalogu nie
ma pliku index.html
" None-nie zezwala na żadne opcje serwera
Polecenie AllowOverridedopuszcza wiele różnych ustawień. W naszym
przypadku zostalo ona wywolane z opcja  None , która nie pozwala na zmiane
żadnego ustawienia przez plik.htaccess. Opcja  ALL pozwala na dowolne
zmiany wprowadzane przez plik.htaccess.
Jeśli chemy aby dostep do naszej witryny byl możliwy tylko dla określonych
18
użytkowników za podaniem hasla musimy w plikuhttpsd.confumieścić
nastepujacy wpis:

AuthType Basic
AuthUserFile /usr/local/apachessl/bin/users
AuthGroupFile /usr/local/apache-ssl/bin/grupy
require valid-user

DyrektywaAuthTypeokreśla typ używanej techniki uwierzytelniania.
DyrektywaAuthGroupFileokreśla grupy użykowników które maja dostep
do naszej strony.
DyrektywaAuthUserFileokreśla ścieżke do pliku, w który zawarci sa użytkownicy
(i ich hasla), którzy maja dostep do naszej witryny.Do dodawania nowych
użykowników mogacych korzystać z naszej strony sluży poleceniehtpasswd,
które znajduje sie w kataloguusr/local/apache-ssl/bin.
2.7 Efektywność
Porównujac serwer HTTP i HTTPS przeslaliśmy 2 pliki:1 rzedu kilkunastu
kilobajtów i drugi o wielkości kilkunastu MB. Podczas pierwszego polaczenia
i ściagniecia pliku malego w przypadku serwera HTTPS czeka sie chwile(ok.2
sekund) dlużej niż w przypadku zwyklego Apache a.Róznica ta zanika jeżeli
operacje powtórzymy kolejny raz. Zwiazane jest to z buforowaniem kluczy
sesyjnych. W przypadku dużych plików istnieje również zauważalna rórnica,
siegajaca nawet 30-40%. Wynika to z kodowania przesylanych danych. Ni-
estety nie mieliśmy możliwości zobaczenia jak to bedzie wygladalo przy pracy
na normalnym modemie.Możemy tylko wnioskować, że różnice bedzie widać
ale mniej niż w przypadku stosunkowo szybkiej sieci, w której przeprowadziliśmy
testy. Polaczenie modemowe jest powolne i bardzo wrażliwe na wszelkie za-
tory w sieci.
19