Instytut Elektroniki

Wydział Automatyki, Elektroniki i Informatyki

Politechniki Śląskiej

SIECI KOMPUTEROWE

LABORATORIUM

Instrukcja do ćwiczenia nr 11

Gliwice 2011

Ćwiczenie 11

Certyfikaty X.509: szyfrowanie
poczty elektronicznej i
wirtualne sieci prywatne

11.1 Podstawy teoretyczne

Celem ćwiczenia jest przedstawienie możliwości zabezpieczania informacji

przesyłanych w sieci Internet przed niepowołanym dostępem oraz zapoznanie
studentów z systemem PKI, czyli infrastrukturą kluczy publicznych i funk-
cjami tego systemu w zakresie szyfrowania informacji w sieciach kompute-
rowych. Przedstawione zostaną podstawowe zagadnienia dotyczące systemu
PKI: klucz prywatny i publiczny, certyfikat, podpis cyfrowy, szyfrowanie i
uwierzytelnianie oraz wykorzystanie systemu PKI do utworzenia bezpiecz-
nego wirtualnego kanału komunikacji dla użytkownika sieci Internet przez
stworzenie prywatnej sieci VPN.

11.1.1 Szyfrowanie

Korzystając z popularnej Wikipedii [1] definicję szyfru można sformu-

łować następująco: szyfr to rodzaj parametryzowanego kodu stosowanego
w celu utajnienia wiadomości tak, by była ona niemożliwa (lub praktycz-
nie niemożliwa) do odczytania przez każdego, kto nie posiada odpowiedniego
klucza. Wiadomość przed zaszyfrowaniem nazywa się tekstem jawnym lub
otwartym a wiadomość zaszyfrowaną – szyfrogramem lub tekstem zaszyfro-
wanym. Sformułowanie „praktycznie niemożliwa” należy interpretować jako
niemożliwą do odtajnienia znanymi narzędziami w rozsądnym czasie (czyli
w czasie kiedy tajność wiadomości jest istotna).

Ćwiczenie 11 - Podstawy teoretyczne

3

Szyfry, a właściwie metody szyfrowanie, dzielą się na dwie grupy:

1. Szyfrowanie niesymetryczne, gdzie do zaszyfrowania i do odszy-

frowania wiadomości używane są różne klucze: klucz publiczny i klucz
prywatny – jak sugerują nazwy, pierwszy z nich może być rozpowszech-
niany bez obawy o tajność wiadomości natomiast drugi wymaga od
strony właściciela ochrony.

2. Szyfrowanie symetryczne, które korzysta z tego samego klucza za-

równo do zaszyfrowania jak i odszyfrowania wiadomości. Klucz wymaga
ochrony i zapewnienia bezpiecznego systemu dystrybucji, co nie było
konieczne w przypadku systemu niesymetrycznego. Wśród szyfrów sy-
metrycznych można wyróżnić:

(a) szyfry blokowe: wiadomość dzielona jest na bloki o określonej dłu-

gości i każdy jest szyfrowany oddzielnie wybranym algorytmem
korzystając z klucza szyfrującego, czego wynikiem jest szyfrogram
o tej samej długości; sposób szyfrowania kolejnych bloków może
być uzależniony od poprzednich szyfrogramów;

(b) szyfry strumieniowe: szyfrowanie polega na zmianie wiadomości

przez połączenie jej (najczęściej operacją XOR) z pseudolosowym
strumieniem, którego zawartość uzależniona jest od klucza szyfru-
jącego; algorytm wytwarzania strumienia pseudolosowego stanowi
o sile szyfru.

Klucze szyfrujące używane w algorytmach symetrycznych są kilkukrotnie
krótsze niż te stosowane przy szyfrowaniu niesymetrycznym zapewniając ta-
ką samą siłę szyfru. Warto tutaj wspomnieć, że tajność wiadomości zależy
przede wszystkim od tajności (i długości) klucza szyfrującego a nie od tajno-
ści algorytmu szyfrowania. Algorytmy szyfrujące uznawane za bezpieczne są
powszechnie znane a mimo to bardzo trudne do odszyfrowania bez znajomo-
ści klucza. Problemem przy szyfrowaniu symetrycznym (które jest szybsze
od niesymetrycznego) jest dystrybucja klucza, który musi być znany zarów-
no stronie wysyłającej jak i odbierającej wiadomość a dopiero wtedy można
utworzyć kanał szyfrujący. Wady tej pozbawiony jest model szyfrowania nie-
symetrycznego, gdzie szyfrowanie oparte jest o parę kluczy: klucz prywatny,
który znany jest tylko właścicielowi i nie wymaga rozpowszechniania oraz
klucz publiczny, który może być przesyłany nieszyfrowanym kanałem i jest
dostępny dla wszystkich.

W szyfrowaniu niesymetrycznym występują dwie operacje, w których wy-

korzystanie kluczy jest różne: podpisywanie wiadomości (cyfrowy podpis)
oraz szyfrowanie wiadomości. Podpis wiadomości (w praktyce podpisywana

Ćwiczenie 11 - Podstawy teoretyczne

4

jest nie wiadomość, a jej skrót (hash) obliczany odpowiednim algorytmem –
w efekcie podpis ma określoną długość niezależnie od długości wiadomości)
obliczany jest przez właściciela klucza prywatnego a jego klucz publiczny
wykorzystywany jest do weryfikacji podpisu. Przy szyfrowaniu wiadomości
używany jest klucz publiczny odbiorcy wiadomości a ten po jej otrzymaniu
może ją odczytać dokonując operacji deszyfrowania korzystając z tajnego
klucza prywatnego.

Algorytmy matematyczne stosowane przy szyfrowaniu nie są tematem tej

instrukcji, ale warto wymienić najpopularniejsze szyfry. W szyfrowaniu sy-
metrycznym najczęściej stosowane algorytmy blokowe to obecnie wychodzący
z użycia standard DES (ang. Data Encryption Standard) oraz jego następ-
ca algorytm AES (ang. Advanced Encryption Standard) nazywany również
Rijndael. Klucze o długości 56 bitów używane przez DES są na dzień dzisiej-
szy zbyt krótkie, AES standardowo używa kluczy 128-bitowych ale specyfi-
kacja dopuszcza także klucze o długości 192 i 256 bitów. Wśród szyfrów stru-
mieniowych najczęściej wykorzystywany jest RC4 (np. w szyfrowaniu WEP
i WPA używanym w sieciach bezprzewodowych) z kluczami od 40 do 128
bitów. Wśród szyfrów niesymetrycznych najczęściej używany jest algorytm
RSA (R. Rivest, A. Shamir and L. Adleman) opierający się na trudności
faktoryzacji (rozkładu na czynniki) dużych liczb.

Za bezpieczne na dzień dzisiejszy (rok 2009) uznaje się algorytmy syme-

tryczne używające kluczy o długości co najmniej 80 bitów co odpowiada klu-
czom RSA o długości ok. 1024 bity [2]. Odpowiednikiem 128-bitowego klucza
w algorytmie symetrycznym jest para RSA o długości 3072 bitów. Natomiast
potrzeba klucza o długości ok. 15360-bitów aby zapewnić siłę szyfrowania od-
powiadającą 256-bitowym kluczom w algorytmach symetrycznych.

Infrastruktura klucza publicznego

Można zauważyć, że publiczna dostępność klucza nie gwarantuje potwier-

dzenia tożsamości osoby oraz powiązania klucza z osobą. Nietrudno sobie
wyobrazić sytuację, że osoba atakująca podmienia klucz publiczny co po-
woduje, że wiadomości szyfrujemy podmienionym kluczem lub sprawdzamy
podpis wygenerowany przez inną osobę. Celem pełnego zabezpieczenia po-
wstał system nazwany infrastrukturą klucza publicznego (PKI, ang. Public
Key Infrastructure), która stanowi zbiór sprzętu, oprogramowania, ludzi za-
sad i procedur związanych z tworzeniem, zarządzaniem, dystrybucją, używa-
nie oraz sprzedażą i unieważnianiem cyfrowych certyfikatów. Certyfikat taki
zawiera klucz publiczny właściciela, jego dane osobowe oraz podpis ośrodka
potwierdzającego tożsamość.

Infrastrukturę klucza publicznego przedstawia rys. 11.1. Dwa główne ele-

Ćwiczenie 11 - Podstawy teoretyczne

5

menty systemu to:

• urząd certyfikacji CA (ang. Certificate Authority), który wydaje cer-

tyfikaty uwierzytelnianym osobom (urządzeniom), czy też inaczej: sub-
skrybentom,

• urząd rejestracji RA ang. Registration Authority, który zbiera wnioski

o wydanie certyfikatu i weryfikuje tożsamość subskrybentów.

Pozostałe elementy systemu są również istotne lecz ich utworzenie jest ła-
twiejsze. Zadaniem RA jest potwierdzenie tożsamości klienta, np. na podsta-
wie dowodu osobistego a zadaniem CA jest wydanie certyfikatu klientowi i po-
twierdzanie jego poprawności w późniejszych transakcjach elektronicznych.
Urząd weryfikacji (VA, Verification Authority) sprawdza tożsamość właści-
ciela certyfikatu, który jako jedyny powinien posiadać odpowiedni klucz pry-
watny. Najważniejszy w systemie wydaje się być ośrodek CA, który podpisuje
certyfikat. Na świecie istnieje określona grupa firm posiadająca status zaufa-
nych urzędów certyfikacji. Ich certyfikaty instalują się zwykle razem z sys-
temem operacyjnym lub przeglądarką internetową. Tożsamość osoby, która
posiada certyfikat podpisany przez jeden z tych ośrodków jest wtedy automa-
tycznie potwierdzana na komputerze użytkownika (status VA posiada system
lub wybrany program). Możliwe jest stworzenie własnego centrum CA, które
po dodaniu przez użytkownika systemu komputerowego do listy zaufanych
ośrodków będzie równoważne z wcześniej wspomnianymi organizacjami.

shop.com

RA

CA

VA

OK

OK

i i

i

Rysunek 11.1: Schemat infrastruktury klucza publicznego (PKI)

Na podstawie rysunku 11.1 można prześledzić funkcjonowanie infrastruk-

tury PKI. Zakładając, że system już działa, to pierwszym krokiem jest ge-
neracja pary kluczy przez użytkownika. Do klucza publicznego użytkownik

Ćwiczenie 11 - Podstawy teoretyczne

6

dodaje informacje osobiste (w tym przykładowo adres e-mail lub adres ser-
wisu www) i przesyła te informacje do RA. Po potwierdzeniu tożsamości
klienta dane te są przesyłane do ośrodka wystawiającego certyfikat, który go
podpisuje i przesyła do klienta. Właściciel certyfikatu podpisując wiadomości
przesyła także swój podpisany klucz publiczny i sprzedawca (ośrodek spraw-
dzający tożsamość klienta) najpierw sprawdza przez VA tożsamość właści-
ciela klucza a następnie używając tego klucza może sprawdzić poprawność
podpisu klienta. Taki model wyklucza konieczność stałego udostępniania mi-
linów kluczy publicznych potrzebnych do szyfrowania i weryfikacji podpisów.

Szczegóły dotyczące sposobu generacji, używania i weryfikacji certyfika-

tów zostaną przedstawione w programie ćwiczenia. Najbardziej znane sys-
temy korzystające z kryptografii niesymetrycznej to wspomniane wcześniej
podpisy elektroniczne wykorzystywane w komunikacji z bankami i urzędami
publicznymi ale także w trakcie prywatnej korespondencji. Najpowszechniej-
sze natomiast wykorzystanie PKI to szyfrowane strony internetowe. Szyfro-
wanie asymetryczne wykorzystywane jest podczas nawiązywania połączenia,
gdzie użytkownik sprawdza tożsamość otwieranej witryny. Następnie two-
rzony jest bezpieczny kanał i uzgadniany jest klucz szyfrujący dla danej sesji
a dalsza transmisja szyfrowana jest algorytmem symetrycznym. Podobne wy-
korzystanie certyfikatów dotyczy także przykładowo szyfrowania WPA i pro-
tokołu EAP w sieciach bezprzewodowych oraz wirtualnych sieci prywatnych.

11.1.2 Wirtualne sieci prywatne

W opisie wirtualnych sieci prywatnych wykorzystany zostanie artykuł dr.

Piotra Zawadzkiego pt. Bezpieczeństwo protokołów VPN przedstawio-
ny na konferencji Sieci Komputerowe w roku 2008 dostępny w publikacji [3].

Celem wirtualnych sieci prywatnych (VPN) jest wydzielenie ruchu grupy

użytkowników z ruchu sieci podkładowej

1

i opcjonalnie jego kryptograficz-

ne zabezpieczenie. W toku rozwoju narzędzi tego typu zaproponowano wiele
rozwiązań znacznie różniących się zakresem stosowalności oraz poziomem ofe-
rowanych zabezpieczeń. W artykule dokonano krytycznej analizy dostępnych
narzędzi o otwartym kodzie źródłowym realizujących swoje własne protoko-
ły (Vtun, OpenVPN), standardy firmowe (L2TP, PPTP) oraz opublikowane
przez IETF (IPsec). W analizie uwzględniono takie czynniki jak moc stoso-

1

Użytkownik podłączający się przez kanał VPN do sieci własnej firmy jest identyfiko-

wany w Internecie jako kolejny komputer działający w strukturach tej firmy niezależnie
od rzeczywistej lokalizacji.

Ćwiczenie 11 - Podstawy teoretyczne

7

wanych algorytmów kryptograficznych, prostota konfiguracji oraz uniwersal-
ność.

Wprowadzenie

Wirtualna sieci prywatne VPN (Virtual Private Network) dzięki zasto-

sowaniu protokołów tunelowania oraz ochrony kryptograficznej umożliwiają
poufną komunikację w ramach publicznej infrastruktury telekomunikacyjnej.
Techniki VPN służą do bezpiecznego udostępniania zasobów wewnętrznych
sieci firmowych użytkownikom zdalnym. Sieci VPN są zazwyczaj realizowane
w oparciu o model end-to-end, w którym zdalny host/użytkownik zestawia
poprzez publiczną sieć transmisji danych bezpieczne, chronione kryptogra-
ficznie połączenie z serwerem firmowym realizującym stosowny protokół do-
stępowy. Inny, konkurencyjny model polega na udostępnieniu chronionego
dostępu do sieci poprzez dostawców usług transmisji danych. Takie rozwią-
zania wymagają aby zarówno wewnętrzna sieć firmowa jak i zdalny użyt-
kownik zestawili chronione tunele z siecią operatora. Przedmiotem dalszych
rozważań będą sieci VPN zbudowane w oparciu o pierwszy model ze względu
na popularność tego typu rozwiązań oraz powszechną dostępność narzędzi
o otwartym kodzie źródłowym, bowiem dostęp do kodu źródłowego ma klu-
czowe znaczenie, gdy idzie o ocenę oferowanego przez dane narzędzie poziomu
bezpieczeństwa.

Popularność rozwiązań VPN wynika z obniżenia kosztów działalności

firm. W rozwoju firm obserwuje się dwa niezależne trendy: powstawanie wie-
lu oddziałów położonych daleko od siebie oraz zdalne wykonywanie zadań
przez pracowników mobilnych (ang. roadwarrior). W przeszłości bezpieczne
współdzielenie zasobów sieciowych przez oddzielone geograficznie oddziały
wymagało wykupienia wydzielonych łączy od dostawców usług transmisji
danych, a zdalny dostęp był możliwy tylko poprzez bardzo wolne i trudne do
zarządzania połączenia modemowe. Obecnie oba te zadania mogą być zreali-
zowane relatywnie tanio dzięki zastosowaniu technik VPN wykorzystujących
Internet jako sieć podkładową, bowiem jego gwałtowny rozwój zapewnia za-
równo wystarczające przepustowości do emulacji ruchu LAN jak i powszech-
ność dostępu pracownikom zdalnym.

W odpowiedzi na zapotrzebowanie rynku zaproponowano wiele rozwią-

zań umożliwiających bezpieczne połączenie geograficznie odległych sieci LAN
i/lub zdalny dostęp pracowników. Podstawowe problemy związane ze skutecz-
ną realizacją sieci VPN obejmują: możliwość realizacji dla różnych topologii
sieci podkładowej, a w szczególności możliwość działanie w sieci z translacją
adresów NAT, automatyczne dostarczenie użytkownikom zdalnym parame-
trów konfiguracji interfejsu VPN, zapewnienie bezpiecznej komunikacji.

Ćwiczenie 11 - Podstawy teoretyczne

8

Rozwiązania kryptograficzne zmierzające do ochrony ruchu sieciowego

muszą być dostosowane do profilu zagrożeń medium transmisyjnego. Internet,
w którym teoretycznie każdy uczestnik może uzyskać dostęp do całego ru-
chu sieci należy traktować jako medium o dostępie współdzielonym. Typowe
zagrożenia związane z komunikacją w tego typu sieciach to podsłuch, podszy-
wanie się poprzez przejęcie sesji lub kradzież tożsamości, blokada usługi DoS
(Denial of Service). Zrealizowanie bezpiecznej komunikacji w sieciach tego
typu nie jest zadaniem trywialnym i powinno obejmować wzajemne uwierzy-
telnienie użytkowników sieci VPN, kontrolę spójności i utajnienie wydzielo-
nego ruchu sieciowego. W idealnym przypadku uwierzytelnienie nie powinno
napastnikowi dostarczyć żadnych informacji, poza faktem dostępu do ser-
wera VPN. W praktyce typowe ataki na stosowane powszechnie protokoły
uwierzytelniające obejmują ataki słownikowe pozwalające złamać hasła o ni-
skiej entropii oraz ataki MITM (man-in-the-middle) umożliwiające kradzież
tożsamości komunikujących się stron. Uwierzytelnienie powinno również do-
starczyć komunikującym się stronom pseudolosowego materiału stosowanego
do wygenerowania kluczy sesyjnych stosowanych następnie do ochrony spój-
ności i poufności ruchu. Utajnienie ruchu jest zadaniem stosunkowo trywial-
nym, bowiem wymaga użycia szyfru o uznanej reputacji. Samo utajnienie
nie zapewnia stuprocentowej ochrony sieci VPN – ruch jest nadal narażony
na ataki podstawieniowe i powtórzeniowe prowadzące w efekcie do blokady
usługi. Ochrona spójności zapewnia obok zabezpieczenia ruchu VPN przed
nieuprawnioną zmianą również wykrycie wspomnianych ataków. Poprawnie
zrealizowany system kontroli spójności wymaga zastosowania kryptograficz-
nych sum kontrolnych MAC (ang. Message Authentication Code) w stosun-
ku do pakietów uzupełnionych liczniki i/lub znaczniki czasowe. Przedmiotem
dalszej analizy będą publicznie dostępne rozwiązania VPN. W analizie zo-
staną uwzględnione przede wszystkim elementy związane z bezpieczeństwem
rozwiązań VPN oraz możliwość ich działania w sieciach z NAT.

Sieci VPN pierwszej generacji

Pierwsze rozwiązania VPN powstawały spontanicznie, aby wypełnić po-

wstałą lukę rynkową. Często były to projekty jednoosobowe i/lub realizowa-
ne przez osoby nie posiadające wiedzy i doświadczenia kryptograficznego. W
efekcie propozycje te były obarczone szeregiem błędów i zapewniające jedy-
nie minimalny poziom ochrony danych. Większość z tych projektów nie jest
już używana i rozwijana. W dalszej części zostaną omówione dwa projekty,
które nadal są w powszechnym użytku.

Ćwiczenie 11 - Podstawy teoretyczne

9

Projekt Vtun Początki projektu Vtun (Virtual Tunnels over TCP/IP) [4]
sięgają roku 1999. Do tunelowania ruchu wielu klientów wystarczy zaledwie
jeden port TCP lub UDP, co znacznie upraszcza konfigurację ścian ognio-
wych. Konfiguracja serwisu nie sprawia również kłopotów w środowiskach
z translacją adresów NAT. Zastosowanie architektury klient serwer sugeruje
obsługę użytkowników mobilnych, jednak dostępność oprogramowania jedy-
nie na platformy linuksowe i BSD znacznie ogranicza jego stosowalność w
tym obszarze. Niestety, problem bezpieczeństwa nie został potraktowany po-
ważnie. Dokumentacja projektu praktycznie nie zawiera żadnych informacji
na ten temat, a wszystkie analizy muszą być wykonane na podstawie analizy
kodu źródłowego.

Uwierzytelnienie końców tunelu odbywa się na podstawie współdzielone-

go sekretu. Do przeprowadzenia dowodu, że obie strony znają sekrety wy-
korzystywany jest protokół wyzwanie-odpowiedź (ang. challenge-response)
bazujący na dobrze znanej funkcji MD5. Po otrzymaniu żądania uwierzytel-
nienia serwer wyznacza liczbę pseudolosową, którą wysyła do klienta. Za-
daniem klienta jest zaszyfrowanie otrzymanego wyzwania używając skrótu
MD5 wyznaczonego ze współdzielonego sekretu jako klucza. Serwer wyko-
nuje analogiczne obliczenia porównując wynik otrzymany od klienta z wyni-
kiem własnych obliczeń. Zgodność wyników oznacza poprawne uwierzytelnie-
nie. Metoda wykorzystująca protokół wyzwanie-odpowiedź jest bardzo czę-
sto stosowana, jako że nie wymaga przesyłania hasła poprzez sieć i jest łatwa
w implementacji. Zasadniczą wadą tej metody jest podatność na atak słow-
nikowy. Napastnik podsłuchujący transmisję uzyskuje dostęp do wyzwania
oraz odpowiedzi. Sprawdzenie czy dane hasło zostało użyte przez administra-
tora jako współdzielony sekret polega na wykonaniu obliczeń identycznych
do wykonywanych przez stronę uwierzytelniającą. Zgodność wyniku z warto-
ścią uzyskaną z nasłuchu oznacza sukces. Siła ataku słownikowego zależy od
rozmiaru słownika oraz entropii współdzielonego sekretu. Jeżeli sekret jest
długi i pseudolosowy to poziom bezpieczeństwa jest wysoki. Niestety, więk-
szość administratorów wybiera hasła łatwe do zapamiętania, a więc łatwe do
odgadnięcia.

W Vtun zastosowano jedynie szyfrowanie danych całkowicie zaniedbując

ochronę spójności. Co więcej, we wczesnych wersjach stosowano szyfrowa-
nie algorytmem Blowfish w trybie elektronicznej książki kodowej ECB (ang.
Electronic Code Book). Tę metodę szyfrowania poddano druzgocącej krytyce
[5] gdzie wskazano na możliwość podmiany części lub całości zaszyfrowanych
pakietów. Atak podstawieniowy jest szczególnie niebezpieczny w środowisku
pakietowym gdzie szyfrowane są dane o pewnej ustalonej strukturze, np. ad-
resy IP zawsze występują w tym samym miejscu szyfrogramu. W najnowszej
wersji Vtun można zabezpieczyć się przed atakiem tego typu wybierając szy-

Ćwiczenie 11 - Podstawy teoretyczne

10

frowanie w trybie wiązania szyfrogramów CBC (Cipher Block Chaining) przy
użyciu algorytmów Blowfish lub AES (Advanced Encryption Standard), jed-
nak nie jest to zachowanie domyślne, a większość administratorów nie jest
świadoma zagrożenia.

Protokół PPTP Protokół PPTP (Point to Point Tunneling Protocol)
opracowano z myślą o użytkownikach mobilnych łączących się zdalnie z we-
wnętrzną siecią firmową [6]. Zadaniem protokołu jest swoista emulacja pracy
modemu ponad siecią pakietową, co umożliwia prostą adaptację połączeń wy-
dzwanianych (ang. dial-up) na platformie Windows. Sam protokół PPTP od-
powiada za zarządzanie sesją VPN natomiast dane transmitowane są poprzez
protokół PPP (ang. Point-to-Point Protocol) tunelowany wewnątrz protokołu
GRE (ang. General Routing Encapsulation). Dane wewnątrz tunelu są szyfro-
wane przy użyciu algorytmu MPPE (ang. Microsoft Point-to-Point Encryp-
tion), a użytkownicy uwierzytelniani na serwerze VPN przy użyciu protokołu
MSCHAPv2 (ang. Microsoft Challenge-Handshake Authentication Protocol
ver. 2) [7].

Protokół PPTP zyskał stosunkowo dużą popularność, ponieważ konfigu-

racja klienta jest stosunkowo prosta a systemy z rodziny Windows są już
w niego standardowo wyposażone począwszy od Windows’98. Klienci i ser-
wery PPTP przez długi czas nie były dostępne na systemy z rodziny Linuks
i BSD, ponieważ uważano, że protokół posiada ograniczenia patentowe. Po
usunięciu problemów prawnych opracowano narzędzie o nazwie PoPToP. Mi-
mo iż protokół adresowany jest do użytkowników mobilnych jego użytkowanie
w środowiskach wykorzystujących ściany ogniowe i translację adresów jest
dość utrudnione, bowiem sesja VPN wymaga dwóch niezależnych połączeń.
Co więcej, wiele tanich routerów nie umożliwia routingu protokołu GRE lub
ma ten routing domyślnie wyłączony. W efekcie istnieje duże prawdopodo-
bieństwo, że klient VPN znajdujący się w nieznanej sieci za NAT nie uzyska
skutecznego połączenia.

Bezpieczeństwo zastosowanej metody uwierzytelnienia pozostawia wie-

le do życzenia. Jak sugeruje nazwa jest to metoda bazująca na protokole
wyzwanie-odpowiedź i umożliwiająca uwierzytelnienie wzajemne komuniku-
jących się stron [8]. Podstawowym problemem zastosowanej metody nie jest
podatność na atak słownikowy, bo jest to podatność implicite związana ze
stosowaniem protokołu wyzwanie-odpowiedź, lecz wadliwa konstrukcja wy-
korzystanej funkcji skrótu. Kluczowym elementem procesu uwierzytelnienia
jest wyznaczenie wartości jednokierunkowej funkcji skrótu NTHash (rys.11.2)
na podstawie hasła użytkownika oraz wyzwania wygenerowanego przez ser-
wer uwierzytelniający i dostępnego również dla napastnika podsłuchującego

Ćwiczenie 11 - Podstawy teoretyczne

11

proces uwierzytelnienia. Współdzielone hasło podaje się na wejście funkcji
MD4. Dane wyjściowe MD4 po uzupełnieniu zerami do długości 21 bajtów
są dzielone na trzy równe części stanowiące niezależne klucze kryptograficzne
dla algorytmu DES. Wyzwanie jest trzykrotnie szyfrowane, za każdym razem
przy użyciu innego klucza. Połączone szyfrogramy stanowią poszukiwaną od-
powiedź.

R0 R1 R2 R3 R4 R5 R6 R7 R8 R9 R10R11 R12R13R14 R15

K8 K9 K10 K11K12 K13

K0 K1 K2 K3 K4 K5 K6 K7

0

0

0

0

0

K14

R23

R22

R21

R20

R19

R18

R17

R16

K15

P0 P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12 P13

MD4(P0-P13)

DES(wyzwanie)

DES(wyzwanie)

DES(wyzwanie)

Rysunek 11.2: Idea działania funkcji NTHash

Napastnik atakujący funkcję NTHash może bardzo efektywnie zorgani-

zować proces obliczeń. W pierwszym etapie dla każdego hasła ze słownika
oblicza skróty MD4, a wyniki indeksuje na podstawie dwóch ostatnich baj-
tów skrótu. Po uzyskaniu danych z nasłuchu napastnik ma do dyspozycji
wartość wyzwania i odpowiedzi. W pierwszym kroku wyzwanie jest szyfro-
wane algorytmem DES przy użyciu wszystkich kluczy posiadających nieze-
rowe dwa pierwsze bajty. Porównanie uzyskanych szyfrogramów z końcową
częścią odpowiedzi pozwala na ustalenie ostatnich dwóch bajtów prawidło-
wego skrótu MD4. W kolejnym etapie sprawdzane są tylko te hasła słownika,
których skróty MD4 kończą się bajtami ustalonymi w poprzednim kroku.
Obecnie narzędzia umożliwiające przeprowadzenie ataku na uwierzytelnienie
przeprowadzone w ramach protokołu PPTP są publicznie dostępne [9].

Rozwiązania bezpieczne

Projektanci rozwiązań VPN szybko zdali sobie sprawę z niedostatków

funkcjonujących projektów. Omówione dalej rozwiązania zapewniają wysoki
poziom bezpieczeństwa, różnią się natomiast pod względem ilości wspiera-
nych platform, złożoności konfiguracji bram i klientów VPN, specyfiką przy-

Ćwiczenie 11 - Podstawy teoretyczne

12

gotowania ścian ogniowych oraz działaniem w środowiskach z translacją ad-
resów NAT.

Projekt tinc Projekt tinc (There is No Cabal) [10] jest aktywnie rozwi-
jany od prawie dziesięciu lat. Celem projektu jest zapewnienie bezpiecznych
połączeń VPN typu punkt-punkt oraz punkt-wielopunkt przeznaczonych dla
użytkowników mobilnych. Dzięki długiej liście wspieranych platform, w tym
Windows, rozwiązanie tinc ma szansę na powszechne stosowanie. Do uwie-
rzytelnienia końców tunelu wykorzystuje się klucze RSA, co zapewnia od-
porność na ataki słownikowy i MITM. Do wad zastosowanego protokołu na-
leży zaliczyć konieczność manualnej wymiany kluczy publicznych, co znacz-
nie utrudnia konfigurację użytkowników mobilnych. W obecnie zastosowanej
metodzie uwierzytelniane są urządzenia końcowe, a nie użytkownicy, co po-
zwala na uzyskanie dostępu do sieci VPN przy użyciu skradzionego laptopa.
Zastosowane metody utajnienia i ochrony spójności należy uznać za zadowa-
lające. Szyfrowanie może być pro-wadzone w trybie wiązania szyfrogramów
przy użyciu szyfrów blokowych o ustalonej reputacji. Zaszyfrowane pakiety
są opatrzone sumami kontrolnymi wyznaczonymi z klucza sesyjnego i zawar-
tości pakietu przy użyciu funkcji SHA-1.

Protokoły IPsec Cechą wyróżniającą IPsec spośród innych realizacji VPN
jest praca bezpośrednio w warstwie sieciowej stosu protokołów (negocjacja
kluczy i uwierzytelnianie wymaga narzędzi w warstwie aplikacji) co pociąga
za sobą szereg konsekwencji.

1. Implementacja IPsec polega na modyfikacji stosu sieciowego systemu

operacyjnego, tak że aplikacje pracujące w wyższych warstwach są w
ogóle nieświadome jego istnienia.

2. Potwierdzenie autentyczności źródła danych dotyczy „tożsamości” ho-

sta źródłowego. Identyfikacja tunelu może być skojarzona z tożsamością
użytkownika poprzez zastosowanie protokołów warstw wyższych.

3. Ochronie kryptograficznej podlega cała transmisja pomiędzy hostami

końcowymi.

IPsec [11] jest zbiorem protokołów umożliwiających uwierzytelnianie, ochro-
nę spójności i szyfrowanie transmisji oraz negocjację kluczy kryptograficz-
nych.

1. Protokół AH jest odpowiedzialny za uwierzytelnianie i ochronę spójno-

ści transmisji. Jest on realizowany jako dodatkowy nagłówek w pakiecie

Ćwiczenie 11 - Podstawy teoretyczne

13

IP zawierający kryptograficzną sumę kontrolną wyliczoną z przesyła-
nych danych oraz niezmiennych pól nagłówka IP przy użyciu klucza
znanego tylko nadawcy i odbiorcy.

2. Protokół ESP zapewnia poufność transmisji oraz ochronę spójności.

Nagłówek kontrolujący protokół ESP następuje zaraz po nagłówku IP
(ewentualnie AH, jeżeli jest równocześnie stosowany), a przed nagłów-
kami protokołów warstw wyższych. Transmisja jest szyfrowana przy
użyciu szyfru symetrycznego uzgodnionego dla danego połączenia a su-
my kontrolne pakietów dodawane na końcu.

3. Protokół IPcomp jest odpowiedzialny za kompresję przesyłanych da-

nych.

4. Klucze używane do ochrony spójności i szyfrowania mogą być statycznie

skonfigurowane lub zmieniane dynamicznie z wykorzystaniem protoko-
łu ISAKMP. W tym drugim przypadku, przed ustanowieniem kluczy
obie strony muszą potwierdzić wzajemnie swoją tożsamość. Proces toż-
samości weryfikacji może odbywać się w oparciu o współdzielone hasło,
certyfikaty lub z wykorzystaniem serwera RADIUS lub Kerberos.

Protokoły IPsec mogą być stosowane w dwóch trybach: transportowym oraz
tunelowym. W pierwszym ochrona jest implementowana bezpośrednio w wy-
syłanym pakiecie, natomiast w drugim, chroniony pakiet jest tunelowany
wewnątrz innego pakietu IP bez ochrony IPsec co powoduje, że jest on trak-
towany jako ładunek danych i zapewnia niezmienność wszystkich pól nagłów-
ka podczas transmisji. Już z pobieżnej prezentacji IPsec widać wyraźnie, że
wspiera on wiele rozwiązań wzajemnie dublujących swoje funkcje, co powo-
duje, że ten sam efekt można uzyskać stosując różne konfiguracje. Obecnie
zaleca się korzystanie z trybu ESP w trybie tunelowym.

Kryptograficzna ochrona tunelu obejmuje szyfrowanie danych w trybie

CBC, ochronę spójności przy użyciu kryptograficznych sum kontrolnych MAC
oraz ochronę przed atakami powtórzeniowymi poprzez wprowadzenie licz-
nika pakietów. Pakiety o niewłaściwej wartości licznika są przez odbiorcę
odrzucane. Umieszczenie losowego wektora początkowego w każdym pakie-
cie powoduje, że szyfrogramy odpowiadające tym samym tekstom jawnym
są różne. Używanie statycznych kluczy do ochrony tuneli jest złą praktyką.
Klucze powinny być co pewien czas wymieniane aby nie dostarczać potencjal-
nym napastnikom wystarczającej ilości materiału do kryptoanalizy. Zadanie
automatycznej negocjacji kluczy realizuje protokół ISAKMP. Przed uzgod-
nieniem klucza jednostki realizujące protokół muszą potwierdzić swoją tożsa-
mość. Podstawową i często jedyną metodą wspieraną przez realizacje IPsec

Ćwiczenie 11 - Podstawy teoretyczne

14

w środowiskach o niewielkich zasobach jest uwierzytelnienie na podstawie
współdzielonego sekretu.

Drugą z metod uwierzytelnienia przewidywaną przez standard jest wyko-

rzystanie algorytmu RSA opcjonalnie wspieranego przez infrastrukturę PKI.
Uwierzytelnienie wzajemne polega na sprawdzeniu podpisów cyfrowych zło-
żonych pod losowymi danymi przy użyciu kluczy prywatnych. Sprawdzenie
poprawności podpisu wymaga znajomości klucza publicznego jednostki skła-
dającej podpis. Klucze te mogą być bezpośrednio zainstalowane w hostach
uwierzytelniających lub wymieniane poprzez sieć a ich autentyczność po-
twierdzana przez jednostkę, której komunikujące się strony ufają. Drugie po-
dejście jest przewidziane dla sieci wspierających użytkowników mobilnych,
jednak administrator sieci musi powołać do życia swoje własne CA (ang.
Certifying Authority) zarządzające certyfikatami lub wykupić stosowne cer-
tyfikaty. Niestety w standardzie nie przewidziano innych mechanizmów wy-
maganych do efektywnego wsparcia użytkowników mobilnych, a mianowicie:
uwierzytelnienia na podstawie loginu i hasła, automatycznej konfiguracji in-
terfejsiu sieciowego klienta oraz obsługę sieci pracujących za NAT. W celu
przezwyciężenia wspomnianych trudności wymagane jest stosowanie rozwią-
zań rozszerzających standard IPsec.

Celem rozszerzenia XAUTH (extended authentication) jest uzupełnienie

IPsec o metody uwierzytelniania bazujące na kontach systemowych, serwi-
sach LDAP lub RADIUS. W pierwszym kroku uwierzytelnienia bazującym
na współdzielonych hasłach lub certyfikatach tworzony jest szyfrowany tu-
nel. Tunel ten służy serwerowi do przeprowadzenia uwierzytelnienia metodą
skonfigurowaną w ramach XAUTH. Utajnienie tunelu zapewnia poufność
przesyłanych danych (loginu i hasła bądź jego skrótu), a uwierzytelnienie
serwera ochronę przed atakiem MITM.

Trudności z obsługą NAT wynikają wprost z realizacji IPsec w warstwie

sieciowej. Router wykonujący NAT rozróżnia połączenia wychodzące na pod-
stawie numeru portu oraz protokołu. Ponieważ w protokołach IPsec nie ma
pojęcia portu, więc połączenia dwóch klientów znajdujących się za NAT uzy-
skują ten sam identyfikator i pakiety przychodzące z Internetu nie mogą być
odpowiednio skierowane do nadawcy. Rozszerzenie NAT-T, które musi być
wspierane na poziomie jądra systemu, umożliwia klientom znajdującym się
za NAT tunelowanie ruchu IPsec w protokole UDP.

Zadaniem promowanego przez Cisco rozszerzenia ModeCfg jest zaopa-

trzenie użytkownika w parametry otoczenia sieciowego widocznego w ramach
sieci VPN. Chodzi tu przede wszystkim o poprawne skonfigurowanie tabli-
cy routingu oraz serwisów DNS. W innym modelu zaproponowanym przez
Microsoft ruch pomiędzy serwerem a klientem jest tunelowany na poziomie
warstwy łącza wewnątrz protokołu L2TP (ang. Link Layer Tunneling Pro-

Ćwiczenie 11 - Podstawy teoretyczne

15

tocol) a ruch wewnątrz tunelu chroniony jest przy użyciu IPsec pracującego
w trybie transportowym. Tunelowanie warstwy drugiej umożliwia w natural-
ny sposób na uzyskanie przez klientów parametrów otoczenia sieciowego przy
użyciu narzędzi wykorzystywanych w sieciach LAN.

Projekt OpenVPN OpenVPN [12] jest dojrzałym rozwiązaniem VPN
dostępnym dla wielu systemów operacyjnych w prawidłowy sposób korzysta-
jącym z dostępnych prymitywów kryptograficznych do zbudowania bezpiecz-
nego tunelu. Zestawienie tunelu składa się z:

• uwierzytelnienia komunikujących się stron na podstawie współdzielo-

nego sekretu lub hierarchii certyfikatów,

• uzgodnienia stosowanych algorytmów kryptograficznych,

• negocjacji i późniejszej aktualizacji klucza sesyjnego,

• szyfrowania i uwierzytelniania przesyłanych danych.

Cała komunikacja odbywa się zaledwie przez jeden port TCP lub UDP, co
sprawia, że dostosowanie konfiguracji ścian ogniowych jak i obsługa NAT
jest zadaniem stosunkowo łatwym. Serwer zapewnia prosty mechanizm auto-
matycznej konfiguracji stosu sieciowego po stronie klienta oraz tunelowanie
ruchu na poziomie warstwy drugiej lub trzeciej.

OpenVPN wspiera wiele różnych mechanizmów uwierzytelniania hostów

i/lub użytkowników. Najprostszy mechanizm wykorzystuje sekret współdzie-
lony przez hosty stanowiące końce tunelu. W istocie nie jest stosowany żaden
mechanizm dowodzenia znajomości tego sekretu, a uwierzytelnianie jest do-
konywane implicite poprzez możliwość skonstruowania poprawnego pakietu.
Współdzielony sekret musi mieć odpowiednią długość, bowiem wprost sta-
nowi klucze używane do szyfrowania i ochrony spójności. Konfiguracja ze
współdzielonym kluczem jest możliwa tylko dla połączeń punkt-punkt.

Ograniczenia tego nie ma już metoda korzystająca z protokołu TLS (ang.

Transport Layer Security). Uwierzytelnienie wzajemne polega na sprawdze-
niu podpisów cyfrowych złożonych pod losowymi danymi przy użyciu kluczy
prywatnych. Sprawdzenie poprawności podpisu wymaga znajomości kluczy
publicznych, których autentyczność musi być potwierdzona przez jednostkę,
której komunikujące się strony ufają. Administrator sieci musi więc powołać
do życia swoje własne CA zarządzające certyfikatami wystawionymi klientom
i serwerom lub wykupić stosowne certyfikaty. Zarządzanie certyfikatami jest
zadaniem trudnym. Duży nakład pracy musi być włożony w poprawną orga-
nizację procesu odnawiania i odwoływania certyfikatów, stąd administratorzy
sieci unikają tej metody uwierzytelnienia.

Ćwiczenie 11 - Podstawy teoretyczne

16

W metodzie uwierzytelnienia z tunelowaniem udało się uzyskać wysoki

poziom bezpieczeństwa przy zachowaniu prostoty zarządzania użytkownika-
mi sieci VPN. W pierwszym etapie uwierzytelnienia za pomocą protokołu
TLS tworzony jest szyfrowany tunel pomiędzy klientem i serwerem VPN,
przy czym sprawdzana jest tylko tożsamość serwera. Wewnątrz szyfrowane-
go tunelu przeprowadza się uwierzytelnienie użytkownika. Wykorzystywany
jest do tego moduł PAM (ang. Pluggable Authentication Modules) umożli-
wiający uwierzytelnienie wieloma różnorodnymi metodami np. w oparciu o
konta użytkowników założone na serwerze lub serwis LDAP (ang. Lightweight
Directory Access Protocol). Metoda z tunelowaniem ma wiele zalet: zestawie-
nie szyfrowanego tunelu zabezpiecza przed atakiem MITM oraz podsłuchem
drugiego etapu uwierzytelnienia, administrator jest uwolniony od konieczność
prowadzenia CA i zarządza kontami dostępu do VPN tak samo jak konta-
mi użytkowników w sieci firmowej. Oczywiście metoda ta niezbyt nadaje się
do zestawiania statycznych tuneli pomiędzy routerami, bowiem każdorazowe
podniesienie tunelu wymaga wpisania hasła.

Ochrona kryptograficzna ruchu w tunelu jest bardzo dobrze przemyślana.

Przesyłane pakiety wyposażone są licznik, który uwzględniany jest w obli-
czeniach kryptograficznej sumy kontrolnej MAC. W odebranych i poprawnie
uwierzytelnionych pakietach sprawdzana jest wartość licznika, a pakiety z
niewłaściwą wartością licznika są odrzucane, co chroni przed atakami po-
wtórzeniowymi. Do szyfrowania wykorzystywane są uznane szyfry blokowe
pracujące w trybie CBC i korzystające z kluczy sesyjnych wyprowadzonych
z pseudolosowego materiału dostarczonego przez procedurę uwierzytelnienia.

Podsumowanie

Rozwiązań VPN pierwszej generacji nie należy obecnie stosować, chyba,

że istnieją ku temu jakieś ważne powody. Zapewniają one zazwyczaj niski
poziom ochrony przesyłanych danych, a co gorsza, mogą stanowić dla na-
pastnika furtkę prowadzącą do wewnętrznej sieci korporacyjnej. Narzędzia
omówione w podrozdziale 11.1.2 zapewniają dobry lub wysoki poziom bez-
pieczeństwa, różnią się jednak znacznie ze względu na ilość wspieranych plat-
form, dostępność wsparcia technicznego i prostotę konfiguracji.

Rozwiązanie tinc jest zdecydowanie najmniej zawansowane i stosunkowo

mało popularne. Zarówno poziomem ochrony danych jak i ilością wspieranych
platform zdecydowanie ustępuje pozostałym dwóm rozwiązaniom.

Dzięki standaryzacji protokoły IPsec doczekały się wielu darmowych i ko-

mercyjnych realizacji. Niestety przeoczenie zagadnień związanych z obsłu-
gą użytkowników mobilnych spowodowało powstanie niestandardowych roz-
szerzeń. Dopuszczenie przez standard różnych konfiguracji prowadzących do

Ćwiczenie 11 - Podstawy teoretyczne

17

tego samego celu oraz wsparcie dla niestandardowych rozszerzeń powoduje
wzajemną niekompatybilność wielu implementacji. W efekcie IPsec sprawia
administratorom wiele problemów konfiguracyjnych. Ostatecznie stosowane
są proste konfiguracje stanowiące wspólny mianownik dla wykorzystywanych
implementacji IPsec. Niestety, konfiguracje te z reguły zapewniają najniższy
poziom ochrony sieci. Wiele z problemów związanych ze skutecznym wdro-
żeniem IPsec zniknie, gdy stosowanie protokołu IPv6 stanie się powszechne.

Projektanci OpenVPN wyciągnęli wnioski z problemów zauważonych przy

wdrażaniu IPsec. OpenVPN w unikalny sposób łączy łatwość wdrożenia
i konfiguracji z wysokim poziomem bezpieczeństwa. Do wad projektu należy
zaliczyć brak oficjalnej specyfikacji zastosowanego protokołu oraz dedykowa-
nych sprzętowych bram VPN wspierających to rozwiązanie.

W tabeli 11.1 zebrano cechy powszechnie stosowanych rozwiązań VPN

istotne z punktu widzenia administratora. W zależności od polityki bezpie-
czeństwa firmy, sposobu korzystania z rozwiązań VPN oraz poziomu zaan-
gażowania w administrację sieci wybiera się zazwyczaj jedno z poniższych
rozwiązań. Bramy VPN realizujące protokół PPTP budowane są zazwyczaj
w oparciu serwery korzystające z różnych odmian systemów Windows ze
względu na bardzo dobre wsparcie dla wspomnianego protokołu i integrację
z systemem uwierzytelniania użytkowników sieci. Bramy wykorzystujące pro-
tokół IPsec realizowane są zazwyczaj jako urządzenia dedykowane pełniące
również funkcję ściany ogniowej. Z kolei OpenVPN jest wykorzystywany naj-
częściej do ochrony niewielkich sieci gdzie wymagany jest niewielki poziom
wiedzy administratora sieci oraz prostota konfiguracji.

Tabela 11.1: Cechy charakterystyczne najbardziej popularnych rozwiązań
wirtualnych sieci prywatnych VPN

PPTP

IPsec

OpenVPN

Poziom bezpieczeństwa

średni

wysoki

wysoki

Obsługa wielu systemów operacyjnych

tak

tak

tak

Dostępność różnych implementacji

tak

tak

nie

Obsługa NAT

słaba

dobra

dobra

Konfiguracja ściany ogniowej

trudna

trudna

łatwa

Dostępność dedykowanych bram VPN

tak

tak

nie

Ćwiczenie 11 - Problemy do rozwiązania przed ćwiczeniem

18

Literatura

1. Wikipedia, wolna encyklopedia, Szyfr, http://pl.wikipedia.org/wiki/

Szyfr

.

2. Wikipedia, The Free Encyclopedia, Key size, http://en.wikipedia.org/

wiki/Key_size

.

3. P. Zawadzki, Bezpieczeństwo protokołów VPN, w pracy zbiorowej pt. „W-

spółczesne aspekty sieci komputerowych”, Tom I, Rozdział 30, str. 319-
328, Wydawnictwa Komunikacji i Łączności, Warszawa 2008.

4. M. Krasnyansky, Vtun - Virtual tunnel, http://vtun.sourceforge.net/.

5. J. Etienne, Security analysis of Vtun, http://off.net/~jme/vtun_secu.

html

.

6. K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, G. Zorn, Point-

to-Point Tunneling Protocol – RFC 2637

, http://www.faqs.org/rfcs/

rfc2637.html

.

7. G. Zorn, Microsoft PPP CHAP Extensions, Version 2 – RFC 2759, http:

//www.faqs.org/rfcs/rfc2759.html

.

8. P. Zawadzki, Ewolucja metod uwierzytelnia, Przegląd Telekomunikacyjny

Vol. LXXIX, No. 4, ss. 99-107, 2006.

9. J. Wright, asleap, http://asleap.sourceforge.net/.

10. tinc, http://www.tinc-vpn.org/.

11. S. Kent, R. Atkinson, Security Architecture for the Internet Protocol –

RFC2401

, http://www.faqs.org/rfcs/rfc2401.html.

12. OpenVPN, http://openvpn.net/index.php.

11.2 Problemy do rozwiązania przed ćwicze-

niem

a) Zapoznaj się z oprogramowaniem Mozilla Thunderbird, w szczególno-

ści z opcjami dotyczącymi konfiguracji kont pocztowych i zarządzania
certyfikatami.

b) Korzystając z instrukcji do ćwiczeń związanych z Intranetem przypo-

mnij sobie pojęcia sieci prywatnej i translacji adresów.

Ćwiczenie 11 - Program ćwiczenia

19

11.3 Program ćwiczenia

Program ćwiczenia obejmuje: stworzenie własnej infrastruktury PKI, za-

instalowanie certyfikatów w używanym systemie operacyjnym a następnie
wysłanie i odebranie podpisanej cyfrowo oraz zaszyfrowanej wiadomości.
W kolejnych etapach laboratorium certyfikaty posłużą do utworzenia szy-
frowanego kanału VPN korzystając z narzędzia OpenVPN.

11.3.1 Generacja certyfikatów

Podczas zajęć wygenerowane zostaną certyfikaty dla poczty elektronicz-

nej oraz dla użytkowników wirtualnej sieci prywatnej. Zadaniem jest stwo-
rzenie pełnej struktury PKI, czyli stworzenie ośrodka CA oraz odpowiednich
certyfikatów, które zostaną podpisane przez CA. Certyfikaty w systemach
typu UNIX najczęściej przechowywane są w postaci plików tekstowych typu
PEM (ang. Privacy Enhanced Mail), które zawierają dane certyfikatu zako-
dowane z użyciem kodu Base64. Systemy rodziny Windows akceptują ten
format, chociaż częściej używają formatu PKCS12 albo DER. Na potrzeby
zajęć wystarczą pliki w formacie PEM a do generacji certyfikatów posłuży
oprogramowanie OpenSSL.

Certyfikat ośrodka uwierzytelniającego

Ośrodek CA powinien używać długiego klucza, ponieważ na nim spo-

czywa rola uwierzytelniania pozostałych użytkowników. Procedurę generacji
certyfikatu dla CA zaczynamy od generacji pary kluczy RSA o określonej
długości:

openssl genrsa -aes256 -out cakey.pem 2048

Zostanie wygenerowana para kluczy RSA (genrsa) o długości 2048 bitów,
która zostanie zapisana w pliku cakey.pem (-out cakey.pem) i zaszyfrowana
szyfrem AES z 256-bitowym kluczem (-aes256). Procedura generacji klucza
na ekranie komputera przebiega następująco:

Generating RSA private key, 2048 bit long modulus
..........................+++
..............................+++
e is 65537 (0x10001)
Enter pass phrase for cakey.pem:
Verifying - Enter pass phrase for cakey.pem:

Ostatnie dwie linijki to pytania o hasło do klucza, które należy zapamię-

tać. Wynikiem jest plik o następującej treści (przykład dla klucza o długości
512 bitów):

Ćwiczenie 11 - Program ćwiczenia

20

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,BA6A5FC701531B03E12B1933B8E52ABB

QhOLd1DrqR5MAzKy9R8EHSx5UclX6UC1HrzBg4pfSG5z1BmpZzB8GIGUTq/kTsr1
H4kuEX//ErPIQLVbDAfPfl0go2z85UOxhg0N1SshsWERCosLc/GyTHdOY3dbKenw
/lwVU2SHPIgy50lCKuu+c2o6StV1oU/jF72vM4wGQDs9PRb7o/2lP4/53Vs+Z2lO
wHABiHcoYMfcFwGwc7YnPKF9+mlJ3T2wnRBeGf7MZlQ2JZ9JUZrYSFFNeZQi4lgA
Lk+kpwhXBi8mQXMucUOSfJ98Tu+Nkmql5XTWn5WXZ6O0Pi38Q12Pzjb7s4JelJRW
0fZNEHjSqAOUPOHdda0k2UDh6cdH8F4hg3btiLrBCNnt71ZxQWKfBLvUxf/kBeyW
tedvOM20+XRMNaalC+tfcmQmgil2qgeKc+qm+dFhMT8=
-----END RSA PRIVATE KEY-----

Dokładne informacje na temat klucza uzyskamy poleceniem:

openssl rsa -in cakey.pem -text

Na ekranie pojawią się informacje zawarte w kluczu, czyli zestaw liczb któ-
re są częścią kluczy lub są pomocne przy szyfrowaniu/deszyfrowaniu al-
gorytmem RSA. Są to (w nawiasach powszechnie stosowane oznaczenia):
modulus (n = pq), publicExponent (e), privateExponent (d), prime1 (p),
prime2 (q), exponent1 (d mod (p − 1)), exponent2 (d mod (q − 1)) i coeffi-
cient (q

−1

mod p). Klucz prywatny stanowi para (n, d) a klucz publiczny

para (n, e) a wartości d i e powiązane są następującą zależnością: de =
1 mod ((p − 1)(q − 1)).

Następny krok to generacja certyfikatu CA, którą wykonujemy polece-

niem:

openssl req -new -x509 -days 3650 -key cakey.pem

-out cacert.pem

Polecenie to wygeneruje na podstawie klucza cakey.pem (-key cakey.pem)
nowy certyfikat (-new) w formacie X.509 (-x509) ważny przez ok 10 lat
(-days 3650) i zapisze go w pliku cacert.pem (-out cacert.pem). Genera-
cja certyfikatu wymaga znajomości hasła, które posłużyło do zaszyfrowania
klucza prywatnego:

Enter pass phrase for cakey.pem:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ’.’, the field will be left blank.
-----
Country Name (2 letter code) [AU]:PL
State or Province Name (full name) [Some-State]:Silesia
Locality Name (eg, city) []:Gliwice

Ćwiczenie 11 - Program ćwiczenia

21

Organization Name (eg, company) [Internet Widgits Pty Ltd]:Politechnika Śląska
Organizational Unit Name (eg, section) []:Laboratorium Sieci Komputerowych
Common Name (eg, YOUR name) []:Sieci Komputerowe - Centrum Autoryzacji
Email Address []:[e-mail]

Spośród wszystkich parametrów które są podawane podczas procedury

generacji istotne są przede wszystkim pola CN (Common Name) oraz E
(Email Address), których zawartość zależy od zastosowania certyfikatów.
Przykładowo dla certyfikatów osobistych używanych do podpisywania/szy-
frowania poczty elektronicznej pole CN powinno zawierać imię i nazwisko
użytkownika poczty a w polu należy zapisać adres e-mail, którego używa
użytkownik. W certyfikatach zabezpieczających dostęp do stron www w polu
CN należy wpisać pełny adres domenowy strony. Złe wartości wpisane w tych
polach powodują, że oprogramowanie korzystające z certyfikatów generuje
alarmy bezpieczeństwa mimo poprawności kluczy prywatnych i publicznych.
W przypadku certyfikatu CA parametry te nie są tak istotne.

Zawartość certyfikatu cacert.pem można podejrzeć używając polecenia:

openssl x509 -in cacert.pem -text

Analizując informacje generowane przez to polecenie można w certyfikacie
poza wprowadzonymi informacjami tekstowymi znaleźć klucz publiczny, czyli
parę liczb (n, e) opisane jako: Modulus i Exponent.

Natomiast sam certyfikat to plik zakodowany za pomocą kodu Base64

o podobnej strukturze jak plik klucza i przedstawia się następująco:

-----BEGIN CERTIFICATE-----
MIIDzjCCA3igAwIBAgIJAJ7Jq+AGGVDSMA0GCSqGSIb3DQEBBQUAMIHNMQswCQYD
VQQGEwJQTDEQMA4GA1UECBMHU2lsZXNpYTEQMA4GA1UEBxMHR2xpd2ljZTEeMBwG
A1UEChQVUG9saXRlY2huaWthIMWabMSFc2thMSkwJwYDVQQLEyBMYWJvcmF0b3Jp
dW0gU2llY2kgS29tcHV0ZXJvd3ljaDEmMCQGA1UEAxMdY2EtbGFiLnNrLWxhYi0w
MS5hZWkucG9sc2wucGwxJzAlBgkqhkiG9w0BCQEWGHJvb3RAc2stbGFiLmFlaS5w
b2xzbC5wbDAeFw0wOTEyMTUxNDQ1MDJaFw0xOTEyMTMxNDQ1MDJaMIHNMQswCQYD
VQQGEwJQTDEQMA4GA1UECBMHU2lsZXNpYTEQMA4GA1UEBxMHR2xpd2ljZTEeMBwG
A1UEChQVUG9saXRlY2huaWthIMWabMSFc2thMSkwJwYDVQQLEyBMYWJvcmF0b3Jp
dW0gU2llY2kgS29tcHV0ZXJvd3ljaDEmMCQGA1UEAxMdY2EtbGFiLnNrLWxhYi0w
MS5hZWkucG9sc2wucGwxJzAlBgkqhkiG9w0BCQEWGHJvb3RAc2stbGFiLmFlaS5w
b2xzbC5wbDBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDIyAPsFW6IKZAcdrSGqXXf
OSbHtwG/Oqv6wMoBnN/kNKwigpGRG0XoxlGSgngDmvfKqKdejsncsIeg96E5Z8zR
AgMBAAGjggE3MIIBMzAdBgNVHQ4EFgQU5kOtmackPNj3eEdKUJCBWwwvgNEwggEC
BgNVHSMEgfowgfeAFOZDrZmnJDzY93hHSlCQgVsML4DRoYHTpIHQMIHNMQswCQYD
VQQGEwJQTDEQMA4GA1UECBMHU2lsZXNpYTEQMA4GA1UEBxMHR2xpd2ljZTEeMBwG
A1UEChQVUG9saXRlY2huaWthIMWabMSFc2thMSkwJwYDVQQLEyBMYWJvcmF0b3Jp
dW0gU2llY2kgS29tcHV0ZXJvd3ljaDEmMCQGA1UEAxMdY2EtbGFiLnNrLWxhYi0w
MS5hZWkucG9sc2wucGwxJzAlBgkqhkiG9w0BCQEWGHJvb3RAc2stbGFiLmFlaS5w
b2xzbC5wbIIJAJ7Jq+AGGVDSMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQAD

Ćwiczenie 11 - Program ćwiczenia

22

QQDDYzmACUVumjiBh5+1Qc3524JDfqtQpeQwIp/LVZBv2zkCXz88lzj68nHtrmF7
A8TO83OJn25we2DwG/O9IMK2
-----END CERTIFICATE-----

Certyfikat osobisty i certyfikat serwera

Poniżej opisano jak wygenerować klucz (plik key.pem), żądanie podpisu

(plik csr.pem) oraz podpisany certyfikat (plik cert.pem). Opisaną proce-
durę należy wykonać dwukrotnie, zmieniając odpowiednio nazwy
plików w podanych poleceniach, aby uzyskać dwa zestawy certyfi-
katów: dla użytkownika (u key.pem, u csr.pem i u cert.pem) oraz dla
serwera (s key.pem, s csr.pem i s cert.pem).

Generowanie klucza prywatnego key.pem dla wybranego serwera lub użyt-

kownika odbywa się podobnie jak generowanie klucza dla CA, czyli należy
wykonać polecenie:

openssl genrsa -aes256 -out key.pem 1024

Otrzymamy klucz prywatny o długości 1024 bitów. Następnie trzeba wyge-
nerować żądanie podpisania certyfikatu (certificate sign request) csr.pem, do
czego służy polecenie:

openssl req -new -key key.pem -out csr.pem

Podobnie jak przy generowaniu certyfikatu dla CA zostaniemy poproszeni
o podanie hasła do klucza oraz danych, które mają być zawarte w żąda-
niu oraz później w podpisanym certyfikacie. Dane te należy uzgodnić z CA
a najważniejsze są jak wspomniano wcześniej pola:

• w certyfikacie użytkownika używanym do zabezpieczenia poczty elek-

tronicznej przede wszystkim pole e-mail, warto także wpisać swoje dane
w polu CN:

Common Name (eg, YOUR name) []:Imię Nazwisko
Email Address []:[e-mail]

• w certyfikacie serwera używanym do zabezpieczenia transmisji pole CN

powinno zawierać pełną nazwę domenową:

Common Name (eg, YOUR name) []:sk-lab-01.aei.polsl.pl

gdzie należy wpisać adres poczty elektronicznej, strony www lub inne-

go serwera (poczty, VPN). Atrybuty opisane jako „extra” można pominąć
pozostawiając puste pola.

Jak pokazuje polecenie wyświetlające zawartość wygenerowanego żądania

zawiera on wyłącznie klucz publiczny:

Ćwiczenie 11 - Program ćwiczenia

23

openssl req -in csr.pem -text

Następny krok to podpisanie żądania (a właściwie jego skrótu SHA1 (-sha1))
używając wcześniej wygenerowanych certyfikatu i klucza prywatnego CA
z określeniem czasu ważności na 1 rok (-days 365):

openssl x509 -req -in csr.pem -out cert.pem -sha1

-CA cacert.pem -CAkey cakey.pem -CAcreateserial
-days 365

Wynikiem jest plik cert.pem, który należy odesłać osobie żądającej podpisu.

Powyżej przedstawiono zestaw podstawowych poleceń oprogramowania

OpenSSL, które pozwolą stworzyć własny system PKI z centrum autoryza-
cji oraz podpisać certyfikaty użytkownikom. Przydatne mogę być ponadto
polecenia konwersji certyfikatów na formaty DER (wymagany przez niektó-
re systemy operacyjne i programy) oraz PKCS12 (format wymagany często
w programach pocztowych, m.in. przez aplikację Mozilla Thunderbird):

openssl x509 -in cacert.pem -outform DER -out cacert.der
openssl x509 -in cert.pem -outform DER -out cert.der
openssl pkcs12 -export -out cert.p12 -in cert.pem

-inkey key.pem -certfile cacert.pem

Podczas eksporty do formatu PKCS12, którego wynikiem będzie plik za-
wierający certyfikat osobisty (-in cert.pem), zaszyfrowany klucz prywat-
ny do tego certyfikatu (-inkey key.pem) oraz certyfikat CA (-certfile
cacert.pem

) należy podać hasło do klucza oraz hasło, którym zostanie za-

szyfrowany plik w formacie PKCS12:

Enter pass phrase for key.pem:
Enter Export Password:
Verifying - Enter Export Password:

Zadania do wykonania

1. Utwórz własne centrum autoryzacji CA i wygeneruj odpowiedni cer-

tyfikat od długości 4096 bitów z kluczem zabezpieczonym algorytmem
AES z 256 bitowym hasłem.

2. Wygeneruj żądania podpisu dla użytkownika poczty (1024 bitów) uży-

wającego adresu [e-mail] (gdzie NN zależy od kom-
putera używanego przez sekcję) oraz dla serwera (2048 bitów) o adresie
sk-lab-NN.aei.polsl.pl.

Ćwiczenie 11 - Program ćwiczenia

24

3. Podpisz wygenerowane żądania używając stworzonego wcześniej cer-

tyfikatu CA. Otrzymane certyfikaty będą wykorzystywane w kolejnych
etapach ćwiczenia. Certyfikat użytkownika poczty należy mu dostarczyć
w formacie PKCS12 z załączonym certyfikatem CA. Plik p12 można
udostępnić poprzez protokół ftp lub http albo przenieść na dysku.

11.3.2 Bezpieczeństwo poczty elektronicznej

Zadaniem w drugiej części ćwiczenia będzie wysłanie podpisanej wiado-

mości, zaszyfrowanie wiadomości oraz sprawdzenie podpisu i odszyfrowanie
wiadomości. Do wykonania tych zadań może zostać użyty dowolny klient
poczty elektronicznej, poniższy opis zakłada korzystanie z darmowego pro-
gramu Mozilla Thunderbird. Ogólnie procedura jest podobna w każdym pro-
gramie pocztowym, który obsługuje elektroniczne podpisy i szyfrowanie wia-
domości:

• Jeżeli posiadamy (wykupiliśmy) certyfikat podpisany przez jeden z ośrod-

ków należących do zaufanych, to importujemy tylko certyfikat użytkow-
nika z kluczem prywatnym do programu.

• Jeżeli posiadamy samodzielnie wygenerowany certyfikat, to należy tak-

że zaimportować certyfikat ośrodka CA – taka sytuacja istnieje w przy-
padku tego ćwiczenia.

Korzystając z Thunderbirda na początek należy wprowadzić nowy organ

certyfikacji, czyli właśnie utworzone CA, do listy zaufanych organów. Otwie-
ramy okno o nazwie Menadżer certyfikatów (Narzędzia → Opcje... →
Zaawansowane → Certyfikaty → Wyświetl certyfikaty), w zakładce Orga-
ny certyfikacji

wybieramy opcję Importuj i wskazujemy na certyfikat nasze-

go ośrodka CA. Podczas importu należy zaznaczyć opcję „Zaufaj temu CA
przy identyfikacji użytkowników poczty”

. Następnie w tym samym menadżerze

certyfikatów

ale w zakładce Twoje certyfikaty należy zaimportować certyfi-

kat osobisty użytkownika poczty [e-mail] potwierdzając
swoje uprawnienia odpowiednim hasłem w razie potrzeby.

Plik PKCS12 (.p12) wymagany przy imporcie certyfikatu użytkownika

zawiera w sobie oprócz klucza i certyfikatu osobistego także certyfikat CA.
Można więc procedurę importu certyfikatów rozpocząć od zakładki Twoje
certyfikaty

, ale wtedy należy po pomyślnej operacji wyszukać w grupie Organy

certyfikacji

własny ośrodek CA (oznaczony jako Urzadzenie zabezpieczające)

i korzystając z polecenia Edytuj... zaznaczyć opcję „Zaufaj temu CA przy
identyfikacji użytkowników poczty”

.

Ćwiczenie 11 - Program ćwiczenia

25

Kolejny krok to utworzenie konta poczty elektronicznej (jeżeli nie zo-

stało ono utworzone wcześniej). Można wykorzystać kreatora kont (Plik →
Nowy → Konto... → Konto pocztowe) podając w odpowiednim miejscu ad-
res e-mail [e-mail], serwer poczty przychodzącej (POP)
sk-lab-NN.aei.polsl.pl

, nazwę użytkownika sklab. Edytując właściwości utwo-

rzonego konta należy przypisać certyfikat osobisty w zakładce Zabezpieczenia
wiadomości

do tworzenia podpisów cyfrowych i szyfrowania (a właściwie de-

szyforwania) wiadomości.

Zadania do wykonania

1. Wyślij podpisaną wiadomość na adres e-mail podany przez prowadzą-

cego (odpowiednia ikona o nazwie Zabezpieczenia, umożliwiająca taką
operację, pojawi się w oknie tworzenia nowej wiadomości).

2. Sprawdź podpis wiadomości otrzymanej w odpowiedzi – czy jest po-

prawny? Jeżeli wiadomość została zaszyfrowana sprawdź, czy potrafisz
ją odszyfrować.

3. Ponownie wyślij wiadomość na wspomniany adres tym razem szyfru-

jąc ją. Zwykle aby zaszyfrować wiadomość trzeba najpierw otrzymać
od adresata wiadomość podpisaną – wraz z podpisem przesyłany jest
certyfikat, czyli klucz publiczny umożliwiający szyfrowania wiadomości
przesyłanych do adresata.

11.3.3 Prywatna sieć wirtualna

Ostatni etap ćwiczenia do konfiguracja serwera i klienta VPN korzystają-

ca z systemu OpenVPN i uwierzytelnienia za pomocą certyfikatów. Wszystkie
stacje zostały przygotowane do pracy w konfiguracji przedstawionej na ry-
sunku 11.3. Punkt dostępowy znajduje się w sieci prywatnej, czyli nie jest
dostępny z Internetu. Pop poprawnym skonfigurowaniu serwera i klienta bę-
dzie możliwy dostęp do tego urządzenia.

Zadania do wykonania

1. Skonfiguruj i uruchom serwer OpenVPN na komputerze opisanym jako

„Serwer VPN”.

2. Skonfiguruj oprogramowanie klienta OpenVPN na komputerze opisa-

nym jako „klient VPN” i podłącz się do skonfigurowanego wcześniej
serwera.

Ćwiczenie 11 - Program ćwiczenia

26

Internet

serwer VPN + NAT

serwer NAT

klient VPN

punkt dostępowy

Rysunek 11.3: Laboratoryjna sieć z serwerem OpenVPN

3. Sprawdź poprawność konfiguracji sieci logując się interfejsu konfigura-

cyjnego „punktu dostępowego” z komputera „klient VPN” (użyj prze-
glądarki internetowej).

Ad.1: Konfiguracja serwera OpenVPN działającego w systemie FreeBSD
została zapisana w pliku /usr/local/etc/openvpn/openvpn.conf. Na ser-
werze umieszczono przykładowy plik, który należy zmodyfikować. Plik ten
zawiera komentarze dotyczące poszczególnych opcji i w większości przypad-
ków można pozostawić ustawienia domyślne. Linie wymagające modyfikacji
to:

port 1194
dev tun
proto udp
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 10.8.0.0 255.255.255.0
push "route 172.16.32.0 255.255.255.0"
cipher AES-128-CBC
comp-lzo

Linie rozpoczynające się od dyrektyw ca, cert i key określają pliki certy-
fikatów, których będzie używał serwer do uwierzytelniania siebie przy łą-

Ćwiczenie 11 - Program ćwiczenia

27

czeniu z użytkownikami. Należy użyć wygenerowanych wcześniej certyfika-
tów, odpowiednio: certyfikatu CA, certyfikatu serwera i klucza prywatnego
serwera w formacie PEM. Można skopiować pliki pod podanymi w pliku
openvpn.conf

nazwami do folderu /usr/local/etc/openvpn albo wpisać

w pliku konfiguracyjnym nowe nazwy plików zawierających certyfikaty i klu-
cze wraz ze ścieżkami. Wymagany plik w linii rozpoczynającej się od dyrekty-
wy dh generujemy zgodnie z instrukcją w przykładowej konfiguracji komendą:

openssl dhparam -out dh1024.pem 1024

Plik ten trzeba będzie także dostarczyć do klienta VPN razem z certyfikatem
CA oraz podpisanym przez CA certyfikatem użytkownika, do którego posiada
on klucz prywatny. Linia server określa z jakimi adresami będzie pracowała
tworzona sieć wirtualna a linia cipher jakiego sposobu szyfrowania będzie
używał tunel podczas transmisji. W wycinku konfiguracji podano jeszcze
linie: dev, proto oraz comp-lzo, które powinny być takie same na serwerze
jak i w konfiguracji klienta oraz port który jest ustawiony domyślnie, ale
także jest istotny w przypadku konfiguracji klienta.

Ostatnia widoczna opcja to push "route net-address mask", która po-

woduje automatyczne dodanie reguły routingu w systemie, który łączy się
z serwerem OpenVPN. Linia jest potrzebna aby dostać się do sieci wewnętrz-
nej serwera VPN, który dodatkowo świadczy usługę translacji adresów. Nale-
ży na serwerze sprawdzić adresy interfejsów sieciowych poleceniem ifconfig
aby zweryfikować poprawność podanego przykładowego wpisu.

Po ustawieniu wszystkich opcji restartujemy serwer poleceniem (które

zadziała poprawnie jeżeli plik konfiguracyjny /etc/rc.conf zawiera wpisy:
openvpn enable="YES"

oraz openvpn if="tun"):

/usr/local/etc/rc.d/openvpn restart

Utworzony wcześniej plik klucza prywatnego serwera jest szyfrowany i pod-
czas startu pojawi się pytanie o hasło do niego. Pytania można uniknąć
usuwając je z pliku klucza poleceniem:

openssl rsa -in key.pem -out np-key.pem

Na nowy plik np-key.pem powinna wskazywać linia key w pliku konfigura-
cyjnym. Po usunięciu hasła chroniącego klucz istotne jest chronienie klucza
przed dostępem, nawet do odczytu, dla innych użytkowników systemu, jednak
może to być konieczne aby nie wpisywać hasła przy każdym uruchomieniu
serwera.

Ćwiczenie 11 - Program ćwiczenia

28

Ad.2: Plik konfiguracyjny klienta w systemie Widnows powinien zostać
umieszczony podkatalogu config folder instalacyjnego oprogramowania Ope-
nVPN i powinien posiadać rozszerzenie ovpn, czyli przykładowo będzie to
plik: C:\Program Files\OpenVPN\config\client.ovpn. Przykładowy plik
client.ovpn

należy skopiować z podkatalogu sample-config i zwrócić uwa-

gę na następujące wpisy:

client
dev tun
proto udp
remote my-openvpn-server 1194
ca ca.crt
cert client.crt
key client.key
;ns-cert-type server
cipher AES-128-CBC
comp-lzo

Dyrektywa client oznacza, że jest to plik konfiguracyjny klienta OpenVPN.
Opcje dev, proto, cipher oraz comp-lzo to odpowiedniki wpisów z kon-
figuracji serwera. W przypadku certyfikatów, czyli linii ca, cert i key po-
stępujemy podobnie jak w przypadku serwera. Decydując się na podawanie
pełnych ścieżek dostępu należy pamiętać o tym, że każdy znak „\” musi być
wpisany podwójnie, np: ca c:\\certyfikaty\\ca cert.pem. Dyrektywwa-
mi cert oraz key należy wskazać pliki certyfikatu i klucza używane wcześniej
do podpisywania poczty elektronicznej.

Certyfikaty generowane wcześniej zgodnie z opisaną procedurą nie za-

wierają ustawionej opcji nsCertType dlatego opcja ns-cert-type została
wyłączona w pliku konfiguracyjnym. Ostatnia opcja, być może najważniej-
sza dla funkcjonowania systemu, to remote gdzie zamiast my-openvpn-server
1194

należy podać odpowiedni adres serwera OpenVPN i port na którym

serwer ten nasłuchuje (zgodny z opcją port konfiguracji serwera).

Po utworzeniu pliku uruchom program OpenVPN GUI, który po uru-

chomieniu dostępny jest w postaci ikony w obszarze powiadomień systemu
Windows (obok zegara). Klikając prawym klawiszem wybierz opcję Connect
i potwierdź swoje uprawnienia do klucza prywatnego podając po zapytaniu
hasło. Po poprawnym połączeniu i przydzieleniu numeru IP uruchom prze-
glądarkę internetową i otwórz interfejs konfiguracyjny punktu dostępowego
(dostępny pod adresem podanym przez prowadzącego zajęcia).

Ćwiczenie 11 - Program ćwiczenia

29

11.3.4 Uwagi końcowe

Powyższa instrukcja aby nie powodować natłoku danych nie zawiera infor-

macji na temat bezpiecznego przechowywania plików certyfikatów a w szcze-
gólności kluczy prywatnych. Klucze te zwykle są dodatkowo szyfrowane algo-
rytmem symetrycznym co stanowi dodatkowe zabezpieczenie, ale nie warto
dawać osobie atakującej nawet szansy na próbę odszyfrowania klucza.

P.S. W związku z problemami związanymi z wpisami do serwerów DNS
może być konieczne zastąpienie domen typu sk-lab-NN.aei.polsl.pl wpisami
w formie s918-l0NN.aei.polsl.pl gdyż inaczej certyfikaty uznawane są za nie-
zaufane.

.tex