Używaj protokołu HTTPS na potrzeby programowania lokalnego

Maud Nalpas

W większości przypadków http://localhost zachowuje się jak HTTPS na potrzeby programowania. Istnieją jednak pewne szczególne przypadki, np. niestandardowe nazwy hostów lub używanie bezpiecznych plików cookie w różnych przeglądarkach, w których musisz wyraźnie skonfigurować witrynę programistyczną tak, aby zachowywała się jak HTTPS, aby dokładnie odzwierciedlać sposób działania witryny w środowisku produkcyjnym. (Jeśli Twoja witryna produkcyjna nie korzysta z protokołu HTTPS, priorytetowo przejdź na ten protokół).

Na tej stronie dowiesz się, jak uruchomić witrynę lokalnie za pomocą protokołu HTTPS.

Uwaga: w tym poście stwierdzenia dotyczące localhost są też ważne w przypadku 127.0.0.1 i [::1] ponieważ oba te adresy opisują adres komputera lokalnego (nazywany też adresem zwrotnym). Aby uprościć instrukcje, nie podajemy w nich numerów portów. Dlatego gdy zobaczysz http://localhost, przeczytaj to jako http://localhost:{PORT} lub http://127.0.0.1:{PORT}.

Krótkie instrukcje znajdziesz w sekcji mkcert – szybkie informacje.**

Uruchamianie witryny lokalnie za pomocą protokołu HTTPS przy użyciu mkcert (zalecane)

Aby używać protokołu HTTPS w lokalnej witrynie programistycznej i uzyskiwać dostęp do https://localhost lub https://mysite.example (niestandardowa nazwa hosta), potrzebujesz certyfikatu TLS podpisanego przez podmiot, któremu ufa Twoje urządzenie i przeglądarka, czyli zaufany urząd certyfikacji (CA). Przed utworzeniem połączenia HTTPS przeglądarka sprawdza, czy certyfikat serwera programistycznego jest podpisany przez zaufany urząd certyfikacji.

Do utworzenia i podpisania certyfikatu zalecamy użycie mkcert, czyli urzędu certyfikacji na wielu platformach. Inne przydatne opcje znajdziesz w artykule Uruchamianie witryny lokalnie za pomocą protokołu HTTPS: inne opcje.

Wiele systemów operacyjnych zawiera biblioteki do tworzenia certyfikatów, np. openssl. Są one jednak bardziej złożone i mniej niezawodne niż mkcert, a także niekoniecznie działają na wielu platformach, co utrudnia dostęp do nich większym zespołom deweloperów.

Uwaga:

• Nigdy nie eksportuj ani nie udostępniaj pliku rootCA-key.pem, który mkcert tworzy automatycznie po uruchomieniu polecenia mkcert -install. Jeśli atakujący uzyska dostęp do tego pliku, może przeprowadzić atak typu man-in-the-middle na dowolną odwiedzaną witrynę. Może przechwytywać bezpieczne żądania z Twojego komputera do dowolnej witryny – banku, podmiotu medycznego czy sieci społecznościowych. Jeśli chcesz sprawdzić, gdzie znajduje się plik rootCA-key.pem, aby upewnić się, że jest bezpieczny, uruchom polecenie mkcert -CAROOT.
• Używaj mkcert tylko na potrzeby programowania – i w związku z tym nigdy nie proś użytkowników o uruchamianie poleceń mkcert.
• Zespoły deweloperów: wszyscy członkowie zespołu powinni zainstalować i uruchomić mkcert osobno (nie należy przechowywać i udostępniać urzędu certyfikacji ani certyfikatu).

Konfiguracja

1. Zainstaluj mkcert (tylko raz).

   Postępuj zgodnie z instrukcjami instalacji mkcert w swoim systemie operacyjnym. Na przykład w macOS:

   brew install mkcert
   brew install nss # if you use Firefox
   

2. Dodaj mkcert do lokalnych głównych urzędów certyfikacji.

   W terminalu uruchom to polecenie:

   mkcert -install
   

   Spowoduje to wygenerowanie lokalnego urzędu certyfikacji. Lokalny urząd certyfikacji wygenerowany przez mkcert jest zaufany tylko lokalnie, na Twoim urządzeniu.

3. Wygeneruj certyfikat dla swojej witryny podpisany przez mkcert.

   W terminalu przejdź do katalogu głównego witryny lub dowolnego katalogu, w którym chcesz przechowywać certyfikat.

   Następnie uruchom:

   mkcert localhost
   

   Jeśli używasz niestandardowej nazwy hosta, np. mysite.example, uruchom:

   mkcert mysite.example
   

   To polecenie wykonuje 2 czynności:

   • Generuje certyfikat dla podanej nazwy hosta.
   • Umożliwia mkcert podpisanie certyfikatu.

   Twój certyfikat jest teraz gotowy i podpisany przez urząd certyfikacji, któremu Twoja przeglądarka ufa lokalnie.

4. Skonfiguruj serwer tak, aby używał protokołu HTTPS i utworzonego właśnie certyfikatu TLS.

   Szczegóły tego procesu zależą od serwera. Oto kilka przykładów:

   👩🏻‍💻 W przypadku Node.js:

   server.js (zastąp {PATH/TO/CERTIFICATE...} i {PORT}):

   const https = require('https');
   const fs = require('fs');
   const options = {
     key: fs.readFileSync('{PATH/TO/CERTIFICATE-KEY-FILENAME}.pem'),
     cert: fs.readFileSync('{PATH/TO/CERTIFICATE-FILENAME}.pem'),
   };
   https
     .createServer(options, function (req, res) {
       // server code
     })
     .listen({PORT});
   

   👩🏻‍💻 W przypadku http-server:

   Uruchom serwer w ten sposób (zastąp {PATH/TO/CERTIFICATE...}):

   http-server -S -C {PATH/TO/CERTIFICATE-FILENAME}.pem -K {PATH/TO/CERTIFICATE-KEY-FILENAME}.pem
   

   -S uruchamia serwer z protokołem HTTPS, -C ustawia certyfikat, a -K ustawia klucz.

   👩🏻‍💻 W przypadku serwera programistycznego React:

   Edytuj plik package.json w ten sposób i zastąp {PATH/TO/CERTIFICATE...}:

   "scripts": {
   "start": "HTTPS=true SSL_CRT_FILE={PATH/TO/CERTIFICATE-FILENAME}.pem SSL_KEY_FILE={PATH/TO/CERTIFICATE-KEY-FILENAME}.pem react-scripts start"
   

   Jeśli na przykład utworzysz certyfikat dla localhost w katalogu głównym witryny:

   |-- my-react-app
       |-- package.json
       |-- localhost.pem
       |-- localhost-key.pem
       |--...
   

   Wtedy skrypt start powinien wyglądać tak:

   "scripts": {
       "start": "HTTPS=true SSL_CRT_FILE=localhost.pem SSL_KEY_FILE=localhost-key.pem react-scripts start"
   

   👩🏻‍💻 Inne przykłady:

   • Serwer programistyczny Angular
   • Python

5. Otwórz w przeglądarce adres https://localhost lub https://mysite.example, aby sprawdzić, czy witryna jest uruchomiona lokalnie za pomocą protokołu HTTPS. Nie zobaczysz żadnych ostrzeżeń w przeglądarce, ponieważ ufa ona mkcert jako lokalnemu urzędowi certyfikacji.

mkcert – szybkie informacje

mkcert – szybkie informacje

Aby uruchomić lokalną witrynę programistyczną za pomocą protokołu HTTPS:

1. Skonfiguruj mkcert.

   Jeśli jeszcze tego nie zrobisz, zainstaluj mkcert, np. w macOS:

   brew install mkcert
   
   
   

   Instrukcje instalacji mkcert w systemach Windows i Linux znajdziesz tutaj.

   Następnie utwórz lokalny urząd certyfikacji:

   mkcert -install

2. Utwórz zaufany certyfikat.

   mkcert {YOUR HOSTNAME e.g. localhost or mysite.example}

   Spowoduje to utworzenie prawidłowego certyfikatu, który mkcert podpisze automatycznie.

3. Skonfiguruj serwer programistyczny tak, aby używał protokołu HTTPS i certyfikatu, który utworzyłeś w kroku 2.

Teraz możesz otworzyć w przeglądarce adres https://{YOUR HOSTNAME} bez ostrzeżeń.

Uwaga: zrób to tylko na potrzeby programowania i nigdy nie eksportuj ani nie udostępniaj pliku rootCA-key.pem. Jeśli chcesz sprawdzić, gdzie znajduje się ten plik, aby upewnić się, że jest bezpieczny, uruchom polecenie mkcert -CAROOT.

</div>

Uruchamianie witryny lokalnie za pomocą protokołu HTTPS: inne opcje

Oto inne sposoby konfiguracji certyfikatu. Są one na ogół bardziej skomplikowane lub bardziej ryzykowne niż używanie mkcert.

Certyfikat podpisany samodzielnie

Możesz też nie używać lokalnego urzędu certyfikacji, takiego jak mkcert, i podpisać certyfikat samodzielnie. Takie podejście ma kilka wad:

• Przeglądarki nie ufają Ci jako urzędowi certyfikacji, dlatego będą wyświetlać ostrzeżenia, które musisz ręcznie pominąć. W Chrome możesz użyć flagi #allow-insecure-localhost, aby automatycznie pominąć to ostrzeżenie w przypadku localhost.
• Jest to niebezpieczne, jeśli pracujesz w niezabezpieczonej sieci.
• Niekoniecznie jest to łatwiejsze lub szybsze niż używanie lokalnego urzędu certyfikacji, takiego jak mkcert.
• Certyfikaty podpisane samodzielnie nie będą działać dokładnie tak samo jak zaufane certyfikaty.
• Jeśli nie używasz tej techniki w kontekście przeglądarki, musisz wyłączyć weryfikację certyfikatu na serwerze. Zapomnienie o ponownym włączeniu tej opcji w środowisku produkcyjnym powoduje problemy z bezpieczeństwem.

Ostrzeżenia wyświetlane przez przeglądarki, gdy używany jest certyfikat podpisany samodzielnie.

Jeśli nie określisz certyfikatu, React's i Vue's opcje HTTPS serwera programistycznego utworzą pod spodem certyfikat podpisany samodzielnie. Jest to szybkie rozwiązanie, ale wiąże się z tymi samymi ostrzeżeniami w przeglądarce i innymi wadami certyfikatów podpisanych samodzielnie. Na szczęście możesz użyć wbudowanej opcji HTTPS w frameworkach frontendowych i określić lokalnie zaufany certyfikat utworzony za pomocą mkcert lub podobnego narzędzia. Więcej informacji znajdziesz w przykładzie mkcert z React.

Dlaczego przeglądarki nie ufają certyfikatom podpisanym samodzielnie?

Jeśli otworzysz w przeglądarce lokalnie działającą witrynę za pomocą protokołu HTTPS, twoja przeglądarka sprawdzi certyfikat lokalnego serwera programistycznego. Gdy zobaczy, że certyfikat został podpisany samodzielnie, sprawdzi, czy jesteś zarejestrowany(-a) jako zaufany urząd certyfikacji. Ponieważ nie jesteś, przeglądarka nie może zaufać certyfikatowi i wyświetli ostrzeżenie, że połączenie nie jest bezpieczne. Jeśli przejdziesz dalej, nadal utworzy połączenie HTTPS połączenie, ale robisz to na własne ryzyko.

Dlaczego przeglądarki nie ufają certyfikatom podpisanym samodzielnie.

Certyfikat podpisany przez zwykły urząd certyfikacji

Możesz też użyć certyfikatu podpisanego przez oficjalny urząd certyfikacji. Wiąże się to z następującymi komplikacjami:

• Musisz wykonać więcej czynności konfiguracyjnych niż w przypadku używania lokalnego urzędu certyfikacji, takiego jak mkcert.
• Musisz użyć prawidłowej nazwy domeny, którą kontrolujesz. Oznacza to, że nie możesz używać oficjalnych urzędów certyfikacji w tych przypadkach:
  • localhost i inne zastrzeżone nazwy domen, takie jak example czy test.
  • Dowolna nazwa domeny, której nie kontrolujesz.
  • Nieprawidłowe domeny najwyższego poziomu. Więcej informacji znajdziesz na liście prawidłowych domen najwyższego poziomu.

Odwrotny serwer proxy

Inną opcją dostępu do lokalnie działającej witryny za pomocą protokołu HTTPS jest użycie odwrotnego serwera proxy, takiego jak ngrok. Wiąże się to z następującymi zagrożeniami:

• Każda osoba, której udostępnisz adres URL odwrotnego serwera proxy, może uzyskać dostęp do Twojej lokalnej witryny programistycznej. Może to być przydatne do prezentowania projektu klientom, ale może też umożliwić nieuprawnionym osobom udostępnianie informacji poufnych.
• Niektóre usługi odwrotnego serwera proxy są płatne, więc cena może być czynnikiem wpływającym na wybór usługi.
• Nowe środki bezpieczeństwa w przeglądarkach mogą wpływać na sposób działania tych narzędzi.

Flaga (niezalecane)

Jeśli w Chrome używasz niestandardowej nazwy hosta, np. mysite.example, możesz użyć flagi, aby wymusić na przeglądarce uznanie mysite.example za bezpieczną. Unikaj tego z tych powodów:

• Musisz mieć 100% pewności, że mysite.example zawsze będzie rozpoznawana jako adres lokalny. W przeciwnym razie ryzykujesz wyciek danych logowania do środowiska produkcyjnego.
• Ta flaga działa tylko w Chrome, więc nie możesz debugować w różnych przeglądarkach.

Dziękujemy wszystkim recenzentom i współtwórcom za ich wkład i opinie, a w szczególności Ryanowi Sleevi, Filippo Valsordzie, Milicy Mihajliji i Rowanowi Merewoodowi. 🙌

Tło banera powitalnego: @anandu na Unsplash, edytowane.