Laboratorium 9 i 10: chroot, ssl

1. Bezpieczne środowisko uruchamiania aplikacji

Jeśli aplikacja (np. serwer http) jest uruchamiana pod systemem operacyjnym, w szczególności np. z uprawnieniami roota, w przypadku umiejętnego wykorzystania błędu atakujący może uzyskać bardzo szerokie uprawnienia, m.in. nieograniczony dostęp do systemu plików.
Aby uniknąć takich zagrożeń:

• należy uruchamiać aplikację z minimalnymi niezbędnymi uprawnieniami, w szczególności jako użytkownik inny niż root. Takie podejście jest szeroko stosowane, np. serwer http apache może być uruchomiony jako użytkownik inny niż root (zwykle http lub www);
• jeśli to możliwe, trzeba zadbać, aby proces miał dostęp do ograniczonych zasobów systemowych.

1.1. Ograniczenie przestrzeni aktywności procesu - chroot

W systemie Linux można uruchomić dowolny proces (i jego procesy potomne) ze zmienionym katalogiem głównym za pomocą polecenia chroot (oraz wywołanie systemowego chroot()). Uruchomiony w ten sposób proces nie może powrócić do rzeczywistego katalogu głównego w systemie plików. Można więc przygotować inny niż główny katalog zawierający pliki niezbędne dla aplikacji np. bibliotki, czy pliki konfiguracyjne. Zwykle trzeba odwzorować część struktury katalogów i plików konfiguracyjnych, np. /etc, /usr/lib/, /var, /proc. Mechanizm chroot może być też przydatny dla celów testowania oprogramowania lub np. zrealizowania środowiska programistycznego ze specyficznym zestawem bibliotek i narzędzi. Do zalet należy także zaliczyć prostotę użycia i brak konieczności modyfikacji jądra systemu operacyjnego.

1.1.1. Przykład użycia polecenia chroot

Jeśli docelowy katalog został przygotowany, można uruchomić proces, np.:

chroot /przygotowany_katalog /usr/sbin/apache2 -k start

1.1.2. Wady chroot

Sam w sobie chroot nie posiada mechanizmów limitowania zasobów używanych przez proces, użycie go nie zabezpiecza więc przed atakami DoS.

Uruchomienie polecenia chroot wymaga uprawnień roota.

Chroot nie zmienia UID i GID procesu. Jeśli aplikacja sama nie zmieni UID, będzie wykonywana z prawami roota.

Istnieją sposoby, które pozwalają procesowi uruchomionemu z prawami roota, wyjście poza określony poleceniem chroot katalog -
opisano je w lekturze uzupełniajacej http://linux-vserver.org/Secure_chroot_Barrier.

Można przy okazji zacytować fragment listu Alana Coxa: "(...) chroot is not and never has been a security tool." :)

1.1.3 Przydatne triki

Jeżeli chcemy mimo wszystko przygotować katalog chroot, możemy ułatwić sobie życie na dwa sposoby. Po pierwsze można przygotować minimalną instalację jakiejś dystrybucji aby uniknąć zgadywania które pliki są potrzebne do pracy naszego programu; dotyczy to zwłaszcza bibliotek korzystających z wielu plików pomocniczych. Trzeba jednak pamiętać, aby nie umieszczać w systemie zbędnych programów z bitem SUID które mogłyby być wykorzystane do "ucieczki" z chroota. Warto też pamiętać o poleceniu

mount --bind /proc /przygotowany_katalog/proc
mount --rbind /dev /przygotowany_katalog/dev

pierwsza wersja powoduje, że pliki z systemu plików (lub jakiegoś katalogu z systemu plików) widocznego jako /proc będą też widoczne w katalogu /przygotowany_katalog/proc. Nie dotyczy to jednak katalogów podmonotwanych wewnątrz proc, np. /proc/sys/fs/binfmt_misc. Natomiast druga wersja obejmuje także katalogi podmontowane wewnątrz bindowanego katalogu.

1.2. Kontentery

Naturalnym roszerzeniem chroota jest objęcie ograniczeniami także innych zasobów niż system plików. W idealnym świecie uruchomiony w takim ulepszonym chroocie - czyli kontenerze - program powinien zachowywać się tak, jakby był uruchomiony na maszynie wirtualnej na tym samym komputerze i z oddzielną kopią tego samego jądra. Jednak ponieważ naprawdę nie uruchamiamy nowego jądra, to nie występuje narzut spowodowany koniecznością obsługi wywołań systemowych przez dwa jądra, wirtualizacją urządzeń sprzętowych itp. Możemy także, jeżeli tego potrzebujemy, osłabić izolację w jakimś miejscu, aby programy bardziej efektywnie współpracowały. Ograniczeniem jest konieczność używania takiego samego jądra we wszystkich używanych kontenerach i systemie bazowym.

W Linuksie implementacja kontenerów opiera się na uogólnieniu pojącia chroot do pojęcia namespace. Są one następujące i pozwalają izolować:

       Namespace   Constant          Isolates
       Cgroup      CLONE_NEWCGROUP   Cgroup root directory
       IPC         CLONE_NEWIPC      System V IPC, POSIX message queues
       Network     CLONE_NEWNET      Network devices, stacks, ports, etc.
       Mount       CLONE_NEWNS       Mount points
       PID         CLONE_NEWPID      Process IDs
       User        CLONE_NEWUSER     User and group IDs
       UTS         CLONE_NEWUTS      Hostname and NIS domain name

Tabelka pochodzi z man namespace(7). Tę stronę podręcznika systemowego należy przeczytać, a strony zależne przejrzeć. Należy także zapoznać się z możliwościami nakładania ograniczeń na procesy za pomocą grup cgroups(7).

Na podstawie tej infrastuktury zbudowanych jest kilka środowisk dających wygodne narzędzia do wirtualizacji, są to. np. Linux Containers (LXC), OpenVZ, Docker.

1.3. Docker

Docker składa się z procesu serwera, który odpowiada za faktyczne tworzenie kontenerów, ich modyfikacje, itp. oraz klienta, którego funkcją jest zapewnianie możliwości korzystania z serwera. Aby skonfigurować nowy kontener, tworzymy w pustym katalogu plik o nazwie Dockerfile z przykładową zawartością:

FROM debian:buster
# O ile chcemy, aby proces działał w środowisku Debian 10
MAINTAINER Kto To Wie
 
RUN apt-get update && apt-get install -y apache2 
 
EXPOSE 80
 
CMD apachectl -D FOREGROUND

pierwsza linia oznacza obraz, z którego korzystamy jako bazowego. Docker ma centralny rejestr obrazów, z których można korzystać przy tworzeniu kontenerów, są w nim w szczególności podstawowe instalacje różnych dystrybucji. Aby uniezależnić się od twórców Dockera, można też uruchomić własny taki serwer.

Linia z wpisem MAINTAINER jest wymagana, ale ma charakter informacyjny. Następnie mamy (być może kilka) linii z poleceniami RUN, opisujące polecenia potrzebne do przygotowania kontenera. Aby nie wykonywać zbyt często tych samych poleceń Docker zapamiętuje stan kontenera po każdej linijce z pliku Dockerfile w sposób analogiczny do snapshotów zwykłych maszyn wirtualnych.

Polecenie EXPOSE 80 udostępnia światu port 80. Polecenie CMD określa komendę, która będzie służyła do faktycznego uruchomienia kontenera - w tym przypadku jest to serwer apache. Gdy podany proces zakończy działanie docker zatrzyma wszystkie procesy w kontenerze

Aby uruchomić nasz kontener wchodzimy do odpowiedniego katalogu i używamy polecenia:

docker build .
docker container run <id_obrazu> lub krócej
docker run <id_obrazu>

Polecenie docker build . zbuduje obraz na podstawie pliku dockerfile (w tym przypadku na Debianie 10, ale np. z dołączonymi naszymi plikami), polecenie docker run id_obrazu uruchomi proces apache2 w nowym kontenerze w środowisku naszego obrazu.

Polecenie

docker images 
lub
docker image ls

pozwala sprawdzić id obrazu.

Jeśli chcemy szybko uruchomić proces w nowym kontenerze (w środowisku Debian 10) bez pisania dockerfile'a, możemy napisać

docker run -t -i debian:buster /bin/bash

Polecenie docker run wykona wtedy kilka kroków:

• Ściągnie obraz debiana bustera, jeśli wcześniej nie był ściągnięty za pomocą polecenia docker pull debian:buster
• Utworzy nowy kontener.
• Nadmontuje nad obrazem warstwę rw.
• Utworzy adres IP
• Uruchomi nowy proces w środowisku określonym przez obraz/warstwę rw

Należy zwrócić uwagę, że istnieje duża różnica między docker run id_obrazu, a docker start id_kontenera. (W tym samym znaczeniu można wykonać docker container run id_obrazu lub docker container start id_kontenera). Run zawsze tworzy nowy kontener.

Kilka przykładów operacji na kontenerach:

docker container ls -a (listowanie wszystkich)
docker container run <id_obrazu> (uruchamia proces w nowym kontenerze, w środowisku obrazu o danym id)
docker container stop <id_kontenera> (zatrzymywanie kontenera)
docker container start <id_kontenera> (uruchamianie zatrzymanego kontenera)
docker container rm <id_kontenera> (usuwanie)
docker container prune (usuwanie wszystkich zatrzymanych)

Można też oczywiście usuwać obrazy (docker image rm id_obrazu lub docker image prune -- usuwa wszystkie nieużywane). Tak jak było widać już wcześniej, np. polecenie docker stop wykona to samo, co docker container stop, ale nie zadziała docker prune, trzeba użyć docker image prune lub docker container prune. Pierwsze usuwa obrazy, drugie kontenery. Warto sprawdzić jakie polecenia są dostępne na danym poziomie: docker --help, docker container --help, docker image --help, docker container ls --help itd. Należy pamiętać, że obraz (image) i kontener (container) to nie to samo. Obraz daje możliwość utworzenia środowiska dla procesu w kontenerze, środowiska opartego na konkretnym systemie operacyjnym (Debianie 9, Debianie 10, Ubuntu itp). Można powiedzieć, iż kontenery korzystają z obrazów, z jednego obrazu może korzystać wiele kontenerów. Więcej informacji na temat przechowywania danych, warstw z których składa się dockerowy storage można znaleźć na https://docs.docker.com/storage/storagedriver/.

1.3.1 Ciąg dalszy

Docker oraz plik Dockerfile mają jeszcze wiele możliwości, których nie poznaliśmy. Co ciekawe, od wersji Docker Engine 19.03, istnieje możliwość pracy w trybie nie roota, w tej wersji cecha ta jest uważana za eksperymentalną. Do używania w tym trybie zalecana jest najnowsza wersja 20.10. Pełna dokumentacja Dockera jest dostepna pod adresem https://docker.com.

2. SSL

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

2.2. 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/).

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

2.3.1. 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ść.

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

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

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

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

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

3. Ćwiczenia

3.1. Docker

• Zainstaluj dockera, pod Debianem 10 wystarczy:

 apt-get install docker.io

docker pull debian:buster
docker run -i -t debian:buster bash -l

• Jako ćwiczenie wykonaj polecenia z treści powyższego modułu.
• Napisz

docker images

• Skasuj wszyskie obrazy.
• Utwórz w katalogu z plikiem Dokerfile podkatalog a z plikami a1 i a2 i podkatalog b z plikiem b1.
• Zmodyfikuj Dockerfile tak, aby kopia podkatalogu a była widoczna w kontenerze (polcenie ADD)
• Zmodyfikuj Dockerfile tak, aby podkatalog b był widoczny w kontenerze (nie jako kopia).

3.2. SSL

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

3.2.1. Tworzenie nowego CA

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)

3.2.2. 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, Common Name musi być nazwą hosta, dla którego wystawiamy certyfikat (inaczej przeglądarka internetowa będzie wyświetlać komunikat o niezgodności). Można wystawić certyfikat dla kilku nazw domenowych, trzeba wtedy umieścić alternatywne nazwy jako rozszerzenie X.509 v3 subjectAltName. Można włączyć rozszerzenia dla tworzenia csr w pliku /etc/ssl/openssl.cnf i dopisać alternatywne nazwy domenowe. A najlepiej przekopiować ten plik do katalogu domowego, zmodyfikować lokalnie i użyć opcji -config $HOME/myopenssl.cnf przy tworzeniu csr.

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

openssl req -in bsk.csr -noout -text

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

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

4. Literatura

Obowiązkowa: ten dokument.
Obowiązkowa: dokument dostępny na Ważniaku (informacje tu mogą być lekko nieaktualne, ale prawdziwe co do koncepcji, niekoniecznie co do implementacji:)
http://wazniak.mimuw.edu.pl/index.php?title=Bezpiecze%C5%84stwo_system%C...

Nieobowiązkowa:
https://www.openssl.org/
https://gnutls.org/