Przejście na HTTPS

Miałem napisać coś o programowaniu, ale przy okazji tego grzebania tu i tam zrobiłem sobie HTTPS na stronach (oprócz bloga, bo się nie da albo ja nie umiem). No, a że lepiej sobie taką świeżo nabytą wiedzę zapisywać (mam taką jedną notkę do której czasem wracam, bo nie osiągnąłem jeszcze takiego poziomu, żeby te dziwne rzeczy wpisywać z głowy) to więc tworzę ten wpis.

Po pierwsze - certyfikacja

Jak rasowy cebulak wybrałem stronę, gdzie certyfikaty SSL dają za darmo czyli StartSSL. Tu jest kilka pułapek. Przede wszystkim po rejestracji i potwierdzeniu konta logowanie odbywa się przy pomocy certyfikatu. Po prostu jakimś magicznym sposobem strona ładuje certyfikat do przeglądarki, który potem służy nam do logowania (pierwszy raz widziałem, żeby jakaś strona coś takiego robiła). Jak certyfikat nam się zgubi to trzeba pisać do supportu i tracić czas. Zdecydowanie mniej wygodne rozwiązanie niż kliknięcie "Przypomnij hasło". Druga pułapka to, że jeśli pociągniemy cały proces przez tę stronę jesteśmy zmuszeni do ustawienia hasła dla certyfikatu. Teraz przy każdym restarcie nginxa muszę wpisywać hasło (i to kilka razy! bo tak!). I tu dochodzimy do kolejnej pułapki. Certyfikaty są darmowe, ale jeśli coś spieprzymy trzeba wyłożyć $25 na anulowanie certyfikatu. A, zapomniałbym, na jedną subdomenę możemy dostać tylko jeden certyfikat (przynajmniej dopóki nie płacimy).

Weryfikacja

Zanim zaczniemy tworzyć certyfikaty należy zweryfikować domenę (nie mylić z weryfikacją konta przy rejestracji). Problem jest tu taki, że system sam wybiera nam kilka możliwych maili pod które gotów jest wysłać kod weryfikacyjny. Na przykład próbując zweryfikować domenę example.com dostałem takie propozycje:

postmaster@example.com
hostmaster@example.com
webmaster@example.com

Czyli nie pozostaje nic innego jak postawić serwer pocztowy (pamiętaj o wpisie MX w DNS!) i/lub stworzyć odpowiednie konto.

Klucz prywatny

Z wyżej podanych powodów zalecam samodzielne wygenerowanie sobie klucza prywatnego i CSR (Certificate Signing Request). W sumie certyfikat też można sobie samemu wygenerować, ale potem przeglądarki będą krzyczeć, że strona wygląda podejrzanie, więc taki certyfikat nadaje się jedynie do testów albo wewnętrznych zastosowań (np. intranet). Polecenie do wygenerowania klucza prywatnego wygląda tak:

$ openssl genrsa -out klucz_prywatny.key 2048

Po wykonaniu zawartość pliku klucz_prywany.key będzie wyglądać mniej więcej tak:

-----BEGIN RSA PRIVATE KEY-----
[dużo dziwnych literek]
-----END RSA PRIVATE KEY-----

Teraz możemy wygenerować CSR:

$ openssl req -new -sha256 -key klucz_prywatny.key -out zapytanie.csr

Konsola poprosi nas o wypełnienia kilku mało znaczących danych (kraj, miasto, organizacja). Ważne są dwa pola. Po pierwsze w Common Name (CN) musisz wpisać nazwę swojej domeny. Po drugie kiedy zapyta się o hasło możesz spokojnie ominąć ten krok wciskająć ENTER (chyba że masz paranoję albo dobre powody, żeby używać dodatkowych zabezpieczeń). Plik CSR powinien zawierać podobnie enigmatyczny ciąg znaków co klucz prywatny z tym, że będzie się zaczynać linijką -----BEGIN CERTIFICATE REQUEST-----. CSR możemy też wygenerować przy pomocy jakiegoś generatora online (zainteresowanych odsyłam do Google), ale wiadomo, że własna konsola jest bardziej tró.

Certyfikat

Pozostaje teraz rozpocząć proces tworzenia certyfikatu (pamiętaj, że każda subdomena wymaga osobnego). Wystarczy wypełnić odpowiednie pola i wkleić treść pliku CSR. Jeśli wszystko pójdzie dobrze to dostaniemy pole tekstowe z treścią certyfikatu (zaczyna się od -----BEGIN CERTIFICATE-----) i kopiujemy go do nowego pliku (wygląda na to, że konwencja zaleca nadanie rozszerzenia .pem).

Konfiguracja serwera

Zakładam, że masz już skonfigurowany i działający serwer Nginx (sorry, z Apachem mi jakoś nie po drodze). W moim wypadku wystarczyło dorzucenie trzech linijek do pliku konfiguracyjnego:

listen               443 ssl;
ssl_certificate      /ścieżka/do/certyfikat.pem;
ssl_certificate_key  /ścieżka/do/klucz_prywatny.key;

I to wszystko... prawie. Po takiej operacji stronka działała poprawnie na moim normalnym kompie, ale na lapku przeglądarka już miała fochy (znaczy mówiła, że jakiś certyfikat jest, ale nie może go zweryfikować). Nie wiem do końca na jakiej zasadzie to działa, ale po kilku godzinach jedna z przeglądarek zaczęła nagle uznawać certyfikat, ale na innej dalej był problem. Okazało się, że potrzeba jeszcze jednego elementu...

Łańcuch zaufania

Oprócz własnego certyfikatu potrzebujemy jeszcze certyfikatów instytucji, które potwierdzą, że nasz jest ok. Na StartSSL te certyfikaty są podpisane jako Root CA i Intermediate Server CA. Po pobraniu należy je dokleić do naszego certyfikatu (nie wiem na ile kolejność ma znaczenie, ale wszystko tutoriale umieszczają te certyfikaty od najmniej zaufanego do najbardziej zaufanego czyli najpierw nasz, a potem kolejno Intermediate i Root).

Jak widać dorobienie sobie kłódki przy adresie nie jest takie trudne. Jeśli jeszcze nie słyszeliście to Google odejmuje punkty za serwowanie stron w zwykłym HTTP. Generalnie, żeby wszystko było tip-top trzeba jeszcze ustawić przekierowanie z HTTP z HTTPS i wypucować stronkę, żeby nie występowało tzw. mixed-content (kiedy dokument z HTTPS zawiera obrazki albo skrypty z adresu HTTP, niektóre przeglądarki to blokują), ale to już pozostawiam czytelnikowi.

Stawianie szyfrowanego połączenia wlan w Linuxie

Miałem dzisiaj nieprzyjemność zrobienia dzisiaj tego (klikany sposób się zbuntował), dlatego zamierzam tą wiedzę zostawić dla potomnych.

Po pierwsze należy wybadać okolice, czy poszukiwaną przez nas sieć w ogóle łapiemy. Należy uruchomić polecenie:

iwlist scan

Program znajduje się w pakiecie wireless-tools (mowa o debianopodobnych dystrubucjach). Jeśli dostaniemy obok naszej sieci podpis "Network is down" to połączenie trzeba najpierw aktywować.

ifconfig wlan1 up

Oczywiście za wlan1 musicsz wstawić identyfikator swojego połączenia. W każdym razie już teraz pożądana sieć powinna być widoczna na wypisanej liście.

Następnie trzeba zapisać gdzieś szyfrowanie. Na początek upewnij się, że masz wpa_supplicant (jak sama nazwa mówi, zajmuje się szyfrowaniem WPA). Następnie wstukaj polecenie:

wpa_passphrase > /etc/wpa_supplicant.conf

Oczywiście wstaw swoją nazwę sieci i hasło do niej. W rezultacie w pliku /etc/wpa_supplicant.conf powinna wylądować mniej więcej taka zawartość:

network={
ssid="costam"
#psk="costammmm"
psk=fe762b507d9e1199445e3e20bd3dc274cc8e5125a06d85dc4d9b67ff3f6ef2a4
}

Tu muszę wspomnieć o dwóch ważnych rzeczach. Po pierwsze wygenerowany psk zależy od ssid, więc jeśli chcesz zmienić ssid to musisz wygenerować ten plik od nowa. Po drugie to jest konfiguracja minimum. wpa_supplicant sam ogarnia większość parametrów połączenia, ale jeśli czytasz ten wpis, bo jest Ci to potrzebne to na pewno nie zadziała, bo... prawa Murphy'ego. Pewnie do poprawnego działania musisz przeryć cały manual do wpa_supplicant i dopisać jakiś gówniany parametr. W każdym razie w większości przypadków to działa.

Kolejna rzecz do uruchomienia:

wpa_supplicant -Dwext -iwlan1 -c/etc/wpa_supplicant.conf -B

Za pierwszym razem uruchom to bez parametru -B na końcu, wtedy wpa_supplicant nie pójdzie w tło, tylko ładnie wypisze, co robi. W zdrowej sytuacji powinno to wyglądać mniej więcej tak:

Trying to associate with c8:64:c7:25:46:aa (SSID='costam' freq=2412 MHz) Associated with c8:64:c7:25:46:aa
WPA: Key negotiation completed with c8:64:c7:25:46:aa [PTK=CCMP GTK=TKIP]
CTRL-EVENT-CONNECTED - Connection to c8:64:c7:25:46:aa completed (auth) [id=0 id_str=]

Jeśli wszystko jest w porządku to ubij to i uruchom z parametrem -B. Do pełni szczęścia pozostało:

dhclient wlan1

I voila, masz internet!

Dzięki takiemu niskopoziomowemu konfigurowaniu połączenia namierzyłem, dlaczego internet mi nie działał. Z jakiegoś dziwnego powodu miałem w pliku konfiguracyjnym od dhclient linijkę reject 192.168.1.1, przez co odrzucał on połączenia z bramą 192.168.1.1, która akurat była bramą routera w moim domu. Komputery są głupie :/