Strona główna › Bezpieczeństwo systemów komputerowych › Laboratorium

VPN

pon., 10/25/2021 - 15:12 — aschubert

Baza dla VPN - SSL

Wersje i nazewnictwo

SSL to standard ochrony warstwy aplikacji wykonany wraz z implementacją przez Netscape Communications Corporation. Powstały wersje SSL v1, v2, v3. Od 1996 roku standard jest rozwijany przez grupe roboczą IETF na bazie SSL v3 jako TLS (Transport Layer Security), powstały wersje standardu TLS 1.0 - RFC 2246, TLS 1.1 - RFC 4346, TLS 1.2 - RFC 5246, TLS 1.3 - RFC 8446.
SSL v1, v2, v3, TLS 1.0, 1.1 są uznawane za niebezpieczne. W tych wersjach istnieją udokumentowane podatności na ataki różnych typów.

Implementacje

Najbardziej popularna to OpenSSL (https://www.openssl.org/). Zawiera implementację standardów SSL v2, v3, TLS 1.0-1.3. OpenSSL to biblioteka wraz z zestawem narzędzi (przede wszystkim program openssl). Alternatywna implementacja: GnuTLS - TLS 1.1-1.3 i SSL v3 (https://www.gnu.org/software/gnutls/).

Koncepcja działania

SSL/TLS zapewnia zestawienie szyfrowanego i uwierzytelnionego kanału dla warstwy aplikacji. W modelu ISO/OSI SSL/TLS znajduje się w
warstwie prezentacji, zatem ponad warstwą transportu (TCP/UDP), ale poniżej warstwy aplikacji.

Przebieg nawiązywania połączenia

  • Serwer uwierzytelniania się przed klientem.
  • Klient i serwer wymieniają między sobą informacje pozwalające uzgodnić im najsilniejsze mechanizmy kryptograficzne jakie obie
    strony wspierają np. algorytm funkcji skrótu kryptograficznego, algorytm służący do szyfrowania.
  • Jeżeli zachodzi taka potrzeba klient uwierzytelnia się przed serwerem.
  • Klient i serwer używając mechanizmów kryptografii klucza publicznego uzgadniają między sobą tajny klucz sesji (shared secret).
  • Zostaje ustanowiony bezpieczny kanał wymiany danych między obiema stronami, szyfrowany kluczem sesji.

Koncepcja SSL/TLS wykorzystuje idee kryptografi symetrycznej i niesymetrycznej. Kryptografia niesymetryczna służy do uwierzytelnienia i ustalenia w bezpieczny sposób klucza sesji. Następnie wykorzystywana jest kryptografia symetryczna (i ustalony klucz sesji), co zwiększa wydajność.

Przebieg sprawdzania autentyczności

To, że uda się zestawić kanał szyfrowany nie oznacza jeszcze, że wiadomo z jakim serwerem http mamy połączenie... Co się stanie, jeśli ktoś podszyje się pod serwer http (co jest popularnym sposobem wyłudzania haseł i innych poufnych informacji)? Przeglądarka, łącząc się z serwerem http, dostaje od niego certyfikat, w którym znajduje się klucz publiczny serwera. Oprócz klucza publicznego
certyfikat zawiera także inne dane:

  • numer wersji standardu X.509 (jest to standard budowy certyfikatu),
  • numer wystawionego certyfikatu,
  • identyfikator algorytmu podpisu certyfikatu,
  • nazwa funkcji skrótu kryptograficznego użyta przez wystawcę,
  • nazwa wystawcy certyfikatu,
  • daty ważności certyfikatu,
  • nazwa podmiotu dla którego wystawiany jest certyfikat,
  • parametry klucza publicznego podmiotu,
  • klucz publiczny podmiotu,
  • opcjonalne rozszerzenia,
  • podpis certyfikatu składany na nim przez wystawcę.

Dzieki tym danym, certyfikat poświadcza związek osoby z kluczami, którymi się posługuje. Ponieważ certyfikat jest podpisany, przeglądarka może sprawdzić autentyczność podpisu. Dokonuje tego za pomocą certyfikatów zawierających klucze publiczne Centrów Certyfikacji (Certification Authorities, CAs), jednostek wystawiających certyfikaty. CAs spełniają rolę zaufanej trzeciej strony (trusted third party) i odpowiedzialne są za poświadczanie tożsamości klientów. Zanim CA podpisze certyfikat podmiotu, sprawdza jego tożsamość (np. przez sprawdzenie dowodu osobistego, czy uprawnień do posługiwania się nazwą instytucji).

Przeglądarka weryfikuje certyfikat za pomocą zbioru certyfikatów zaufanych CA. Jeśli weryfikacja podpisu nie powiedzie się, generowane jest ostrzeżenie. Ostrzeżenia są tworzone także, jeśli nie zgadzają się inne elementy certyfikatu, np: data ważności, czy nazwa domeny (gdy serwer wyśle certyfikat zawierający inna nazwę domenową, niż ta która znajduje się w URL).

Poziomy walidacji dla SSL

1) Certyfikaty DV (Domain Validation)

Przed wystawieniem certyfikatu dochodzi jedynie do weryfikacji dostępu do domeny, zwykle w sposób automatyczny. Nie są sprawdzane dane organizacji, która ubiega się o certyfikat.

2) Certyfikaty OV (Full Organization Validation)

CA dokonuje weryfikacji danych właściciela witryny i samego podmiotu, który ubiega się o certyfikat (tożsamości firmy).
W efekcie, w certyfikacie można znaleźć nazwę i dane firmy, oraz także potwierdzenie, że dany podmiot jest właścicielem strony. Ze względu na bardziej dokładną weryfikację, cena certyfikatu OV jest zwykle wyższa niż DV.

3) Certyfikaty EV (Extended Validation)

Ten proces polega na najdokładniejszej weryfikacji i trwa najdłużej. Walidacja danych firmy odbywa się m.in. na podstawie rządowych baz. Sprawdzane jest też prawo do posługiwania się domeną.

Własne CA

Na potrzeby własnej instytucji można utworzyć własne CA i z jego pomocą generować certyfikaty. Może to ograniczyć koszty utrzymywania certyfikatów podpisywanych przez zaufane CA np. Verisign. Tak utworzone certyfikaty spowodują, że np. przeglądarka internetowa lub inne aplikacje będą generować ostrzeżenia związane z brakiem możliwości weryfikacji podpisu (brakiem zaufania do CA podpisującej wystawiony certyfikat). By uniknąć generowania takich ostrzeżeń, certyfikat własnego CA należy zaimportować do przeglądarki.
Jeśli chcemy mieć bezpłatny certyfikat podpisany przez rozpoznawalne, zaufane CA, można skorzystać z certyfikatów
https://letsencrypt.org/. Są to certyfikaty tylko DV, wystawiane na okres 3 miesięcy.

PKI

Wyżej opisana koncepcja obiegu informacji związanych z wystawianiem certyfikatów dla podmiotów, wraz z istnieniem organizacji CA poświadczających związek certyfikatu z konkretną instytucją lub osobą nosi nazwę Infrastruktury Klucza Publicznego (ang. Public Key Infrastructure), w skrócie PKI.
Struktura PKI podlega standaryzacji i opiera się na dwóch elementach. Jednym jest standard X.509 opisujący strukturę certyfikatów oraz drugi określany mianem PKCS (ang. Public Key Cryptography Standards).

ECC vs RSA

Wszystkie przykłady w tym dokumencie zakładają wykorzystanie kryptografii RSA. Współczesne wersje OpenSSL
mogą korzystać z kryptografii opartej o krzywe eliptyczne (ang. Elliptic Curve Cryptography (ECC)).
Główne elementy implementacji ECC w OpenSSL to Elliptic Curve Digital Signature Algorithm (ECDSA) i Elliptic Curve Diffie-Hellman (ECDH).
ECDSA służy do podpisywania i weryfikacji podpisów w oparciu o kryptografię krzywych eliptycznych, a ECDH to algorytm bezpiecznego uzgadniania kluczy, np. wspólnego klucza dla szyfrowania symetrycznego.

Dużą zaletą ECC jest znacznie mniejsza długość klucza, więc zyskuje się na wydajności.
Poniższa tabela porównuje klucze o takiej samej sile kryptograficznej. Jak widać, długość klucza dla RSA
szybko rośnie. Uzyskiwanie coraz większej siły kryptograficznej dla RSA może być, w sensie
wydajnościowym, nieopłacalne. Należy więc oczekiwać, że kryptografia ECC będzie coraz szerzej stosowana
w certyfikacji oferowanej przez organizacje CA. Certyfikaty RSA są jednak nadal powszechnie tworzone i używane.

Długość klucza dla kryptografii symetrycznej Długość klucza dla kryptografii niesymetrycznej RSA Długość klucza dla kryptografii niesymetrycznej ECC
80 1024 160
112 2048 224
128 3072 256
192 7680 384
256 15360 512

Przykład użycia openssl

W poniższym przykładzie będziemy posługiwać się bezpośrednio programem openssl. Można używać też pod Debianem 10
/usr/lib/ssl/misc/CA.pl, jest to opakowanie do programu openssl, aby łatwiej było tworzyć m.in. własne CA, prośby o certyfikację
itp. Por. /usr/lib/ssl/misc/CA.pl -help

Tworzenie nowego CA

Popatrzmy na polecenie

openssl genrsa -out ca.key 2048

Klucz prywatny naszego CA wygenerowany w powyższy sposób nie będzie chroniony! Jak to zmienić i czy warto?
Następnie tworzymy certyfikat CA (ważność: 3650 dni, self signed (opcja -x509)):
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt
Podajemy niezbędne dane:

Country Name (2 letter code) [AU]:PL
State or Province Name (full name) [Some-State]:Mazowieckie
Locality Name (eg, city) []:Warszawa
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MIM UW
Organizational Unit Name (eg, section) []:BSK LAB
Common Name (eg, YOUR name) []:CA BSK LAB
Email Address []:ca@mimuw.edu.pl
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []: pomijamy
An optional company name []: pomijamy

W efekcie, w katalogu bieżącym, powstał certyfikat naszego CA (ca.crt) oraz klucz prywatny CA (ca.key)

Tworzenie prośby o certyfikację

Tworzymy klucz prywatny i prośbę do CA (bsk.csr) o certyfikowanie wygenerowanego klucza publicznego. Czy klucz prywatny powinien być chroniony hasłem (zaszyfrowany)?

openssl genrsa -out bsk.key 2048
openssl req -new -key bsk.key -out bsk.csr

Podajemy dane

Country Name (2 letter code) [AU]:PL
State or Province Name (full name) [Some-State]:Mazowieckie
Locality Name (eg, city) []:Warszawa
Organization Name (eg, company) [Internet Widgits Pty Ltd]:MIM UW
Organizational Unit Name (eg, section) []:BSK LAB
Common Name (eg, YOUR name) []:bsklabXX.mimuw.edu.pl 
       (zastąp XX numerem twojej stacji roboczej)
Email Address []: bsklab13@mimuw.edu.pl
 
A challenge password []: pomijamy
An optional company name []: pomijamy

Ponieważ klucza publicznego używać będziemy do zestawiania połączeń https, subjectAltName musi zawierać nazwę hosta, dla którego wystawiamy certyfikat (inaczej przeglądarka internetowa będzie wyświetlać komunikat o niezgodności). Przy czym OpenSSL po cichu kopiuje do subjectAltName wpisywaną w powyższym dialogu zawartość pola Common Name.
Można wystawić certyfikat dla kilku nazw domenowych, trzeba wtedy dodać alternatywne nazwy do pola subjectAltName.

Oglądamy nasz csr, sprawdzamy, czy wszystko się zgadza:

openssl req -in bsk.csr -noout -text

Wystawianie certyfikatu (podpisywanie utworzonej prośby kluczem prywatnym CA)

openssl x509 -req -in bsk.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out bsk.crt

Oglądamy wystawiony certyfikat:
openssl x509 -in example.org.crt -noout -text
Na jak długo został wystawiony certyfikat? By zmienić okres ważności, należy zmienić liczbę dni (tak jak w przypadku tworzenia CA, patrz wyżej).
Na końcu gotowy certyfikat znajduje się w pliku bsk.crt
Do podpisywania certyfikatów można też używać modułu openssl ca (zamiast openssl x509).

Konfiguracja obsługi protokołu HTTPS na przykładzie serwera Apache

Do katalogu /etc/ssl/certs/ skopiuj podpisany certyfikat wystawiony dla hosta (bsk.crt). Do katalogu /etc/ssl/private skopiuj odpowiadający certyfikatowi klucz prywatny (bsk.key).
Należy teraz włączyć mod-ssl poleceniem:
a2enmod
po ukazaniu się listy dostępnych modułów, należy wybrać ssl.
Następnie trzeba włączyć obsługę konfiguracji ssl:
a2ensite
i wybrać default-ssl.
W pliku konfiguracyjnym /etc/apache2/sites-available/default-ssl ustawić odpowiednie nazwy zainstalowanego certyfikatu i klucza prywatnego:

SSLCertificateFile /etc/ssl/certs/bsk.crt
SSLCertificateKeyFile /etc/ssl/private/bsk.key

i zrestartować serwer http:

systemctl restart apache2

Teraz już można się cieszyć dostępem po https. Można to sprawdzić przeglądarką:
https://bsklab13.mimuw.edu.pl/
Przeglądarka wyświetli ostrzeżenie mówiące o braku zaufania do CA, które podpisało certyfikat dla hosta solab13 (czyli CA, które stworzyliśmy na początku tych ćwiczeń). Jeśli ufasz swojemu lokalnemu CA, możesz zaimportować do przeglądarki certyfikat lokalnej CA z pliku DemoCA/cacert.pem. Po zaimportowaniu certyfikatu CA, przeładuj stronę - nie powinna już generować ostrzeżeń.
Połącz się ze stroną https://localhost.
Dlaczego generowane jest ostrzeżenie?

Dodatkowe materiały

Tworzenie sieci VPN

Wymagania dotyczące poufności, tajemnic produkcyjnych firm oraz konieczność umożliwiania pracownikom pracy zdalnej, w tym z domu, powoduje, że konieczne jest wprowadzanie metod udostępniania sieci wewnętrznej firmy przez szyfrowane kanały. Zwykle praca bezpośrednio za pomocą protokołu SSH jest niewystarczająca, dlatego sięga się po bardziej specjalizowane rozwiązania, takie jak VPN, które pozwalają na przekazywanie szyfrowanym kanałem całego ruchu sieciowego (bez konieczności ustanawiania odrębnych tuneli dla różnych aplikacji oraz bez ograniczenia się do protokołu TCP).

Wśród rozwiązań VPN dostępne są dwa podejścia:

  • tunelowanie ruchu VPN w protokole SSL,
  • przekazywanie ruchu VPN za pomocą protokołu IPsec.

Zasadnicza różnice między tymi dwoma podejściami:

  • tunelowanie w protokole SSL jest prostsze do zapewnienia,
  • tunelowanie w protokole SSL ma lepiej przetestowaną infrastrukturę (znacznie więcej użytkowników stosuje SSL),
  • tunelowanie w protokole SSL pozwala na korzystanie z powszechniej znanych mechanizmów,
  • tunelowanie w protokole IPsec można wykorzystywać przy uboższej infrastrukturze stosu sieciowego komputera.

Do tworzenia sieci VPN na bazie protokołu SSL służy OpenVPN.
Do tworzenia sieci VPN na bazie IPsec służy Openswan.

Dalsze informacje do przeczytania przed zajęciami:

Przykładowa konfiguracja VPN

Celem ćwiczeń jest budowanie poprawnej konfiguracji VPN krok po kroku.

Załóżmy, że komputer serwera VPN to vpn-server (adres ip ip-server), a klienta to vpn-client (adres ip ip-client).

Będziemy stawiać tunel VPN o adresach 10.0.0.1 (serwer) / 10.0.0.2 (klient)

1 instalacja pakietów openvpn

Na obu komputerach:

apt-get install openvpn

2 konfiguracja openvpn bez autoryzacji i szyfrowania

vpn-server# openvpn --ifconfig 10.0.0.1 10.0.0.2 --dev tun
vpn-client# openvpn --ifconfig 10.0.0.2 10.0.0.1 --dev tun --remote 192.168.1.10

Sprawdź, czy serwer nasłuchuje na porcie 1194 (:openvpn):

vpn-server# netstat -l | grep openvpn

Sprawdź, czy jest połączenie po vpn między komputerami:

vpn-client# ping 10.0.0.1
vpn-server# ping 10.0.0.2

3 konfiguracja openvpn ze wspólnym kluczem

Stwórz klucz:

vpn-server# openvpn --genkey --secret vpn-shared-key

Przegraj klucz do komputera klienta:

vpn-server# scp vpn-shared-key root@vpn-client:

Włącz vpn:

vpn-server# openvpn --ifconfig 10.0.0.1 10.0.0.2 --dev tun --secret vpn-shared-key 0
vpn-client# openvpn --ifconfig 10.0.0.2 10.0.0.1 --dev tun --remote ip-server --secret vpn-shared-key 1

Upewnij się, że tunel działa. Sprawdź, czy klient może korzystać z tunelu gdy nie ma klucza.

4 konfiguracja openvpn z certyfikatami

Do wygenerowania certyfikatów wykorzystaj skrypty z /usr/share/easy-rsa

Ustaw właściciela certyfikatu (zmienne w pliku vars) na PL/Mazowieckie/Warszawa/mimuw-bsk-lab

Następnie wygeneruj certyfikaty dla centrum autoryzacji, klienta i serwera przez:

vpn-server# . vars
vpn-server# ./clean-all
vpn-server# ./build-ca
vpn-server# ./build-dh
vpn-server# ./build-key-server vpn-server
vpn-server# ./build-key vpn-client

Przekopiuj certyfikaty ca.cert, vpn-client.crt i klucz vpn-client.key na vpn-client.

vpn-server# openvpn --dev tun --tls--server --ifconfig 10.0.0.1 10.0.0.2 --ca ca.crt --cert vpn-server.crt --key vpn-server.key --dh dh1024.pem
vpn-client# openvpn --dev tun --tls-client --ifconfig 10.0.0.2 10.0.0.1 --ca ca.crt --cert vpn-client.crt --key vpn-client.key --remote [ip-vpn-server]

Ćwiczenie punktowane

  1. Wygeneruj klucze, pozwalające na stworzenie VPN
  2. Utwórz dwie maszyny wirtualne
  3. Na każdą z nich sprowadź klucze utworzone w punkcie pierwszym
  4. Skonfiguruj na maszynach VPN tak, aby łączyły się ze sobą po adresach 172.16.0.134 i 172.16.0.135
  5. Sprawdź za pomocą polecenia ping, że maszyny są połączone
  6. Skrypt wykonujący czynności z punktów 3-5 oraz inne czynności, które są potrzebne do zrealizowania zadania, wgraj do Moodle.