Na tej stronie znajdziesz wskazówki dotyczące konfigurowania protokołu HTTPS na serwerach, w tym te kroki:
- Tworzenie pary kluczy publicznego i prywatnego RSA o długości 2048 bitów.
- wygenerowanie żądania podpisania certyfikatu (CSR), które zawiera Twój klucz publiczny;
- Udostępnianie CSR urzędowi certyfikacji, aby otrzymać ostateczny certyfikat lub łańcuch certyfikatów.
- Zainstaluj ostateczny certyfikat w miejscu niedostępnym przez sieć, takim jak
/etc/ssl(Linux i Unix) lub tam, gdzie wymaga tego IIS (Windows).
generować klucze i żądania podpisania certyfikatu.
W tej sekcji do generowania kluczy prywatnych i publicznych oraz CSR używany jest program wiersza poleceń openssl, który jest dostępny w większości systemów Linux, BSD i Mac OS X.
Generowanie pary kluczy publicznego i prywatnego
Na początek wygeneruj parę kluczy RSA o długości 2048 bitów. Krótszy klucz można złamać za pomocą ataków typu brute force, a dłuższe klucze wykorzystują niepotrzebne zasoby.
Aby wygenerować parę kluczy RSA, użyj tego polecenia:
openssl genrsa -out www.example.com.key 2048
Wynik:
Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)
Generowanie żądania podpisania certyfikatu
W tym kroku należy umieścić klucz publiczny oraz informacje o organizacji i witrynie w żądaniu podpisania certyfikatu lub CSR. Polecenie openssl poprosi Cię o podanie wymaganych metadanych.
Uruchom to polecenie:
openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr
Dane wyjściowe:
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]:CA
State or Province Name (full name) [Some-State]:California
Locality Name (for example, city) []:Mountain View
Organization Name (for example, company) [Internet Widgits Pty Ltd]:Example, Inc.
Organizational Unit Name (for example, section) []:Webmaster Help Center Example
Team
Common Name (e.g. server FQDN or YOUR name) []:www.example.com
Email Address []:webmaster@example.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Aby sprawdzić ważność CSR, uruchom to polecenie:
openssl req -text -in www.example.com.csr -noout
Odpowiedź powinna wyglądać tak:
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=CA, ST=California, L=Mountain View, O=Google, Inc.,
OU=Webmaster Help Center Example Team,
CN=www.example.com/emailAddress=webmaster@example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:ad:fc:58:e0:da:f2:0b:73:51:93:29:a5:d3:9e:
f8:f1:14:13:64:cc:e0:bc:be:26:5d:04:e1:58:dc:
...
Exponent: 65537 (0x10001)
Attributes:
a0:00
Signature Algorithm: sha256WithRSAEncryption
5f:05:f3:71:d5:f7:b7:b6:dc:17:cc:88:03:b8:87:29:f6:87:
2f:7f:00:49:08:0a:20:41:0b:70:03:04:7d:94:af:69:3d:f4:
...
Przesyłanie żądania podpisania certyfikatu do urzędu certyfikacji
Różne urzędy certyfikacji (CA) wymagają przesyłania do nich żądań CSR na różne sposoby. Może to być na przykład formularz na stronie internetowej lub e-mail do zespołu pomocy. Niektórzy dostawcy usług zaufania lub ich sprzedawcy mogą nawet zautomatyzować część lub całość procesu, w tym w niektórych przypadkach parowanie kluczy i generowanie CSR.
Prześlij CSR do CA i postępuj zgodnie z jego instrukcjami, aby otrzymać ostateczny certyfikat lub łańcuch certyfikatów.
Różne urzędy certyfikacji pobierają różne kwoty za usługę poświadczenia klucza publicznego.
Dostępne są też opcje mapowania klucza na więcej niż 1 nazwę DNS, w tym kilka różnych nazw (np.wszystkie domeny example. com, www.example.com, example.net i www.example.net) lub nazwy z symbolem wieloznacznym, np.*.example.com.
Skopiuj certyfikaty na wszystkie serwery front-end w miejscu niedostępnym przez sieć, takim jak /etc/ssl (Linux i Unix) lub gdziekolwiek wymaga tego IIS (Windows).
Włączanie protokołu HTTPS na serwerach
Włączenie protokołu HTTPS na serwerach jest kluczowym krokiem w zapewnieniu bezpieczeństwa Twoich stron internetowych.
- Aby skonfigurować serwer pod kątem obsługi HTTPS, użyj narzędzia do konfiguracji serwera Mozilli.
- Regularnie testuj swoją witrynę za pomocą testu serwera SSL Qualys i upewnij się, że otrzymujesz ocenę co najmniej A lub A+.
W tym momencie musisz podjąć ważną decyzję operacyjną. Wybierz jedną z tych opcji:
- Przypisz osobny adres IP do każdej nazwy hosta, z której serwer WWW udostępnia treści.
- Użyj hostingu wirtualnego na podstawie nazwy.
Jeśli używasz różnych adresów IP dla każdej nazwy hosta, możesz obsługiwać zarówno HTTP, jak i HTTPS dla wszystkich klientów. Jednak większość operatorów witryn korzysta z wirtualnego hostingu opartego na nazwie, aby oszczędzać adresy IP i ogólnie ułatwić sobie pracę.
Jeśli usługa HTTPS nie jest jeszcze dostępna na serwerach, włącz ją teraz (bez przekierowywania HTTP do HTTPS). Więcej informacji znajdziesz w artykule Przekierowywanie ruchu HTTP do HTTPS. Skonfiguruj serwer WWW tak, aby używał zakupionych i zainstalowanych certyfikatów. Możesz skorzystać z generatora konfiguracji Mozilli.
Jeśli masz wiele nazw hostów lub subdomen, każda z nich musi używać odpowiedniego certyfikatu.
.Teraz i regularnie w trakcie istnienia witryny sprawdzaj konfigurację HTTPS za pomocą testu serwera SSL Qualys. Twoja witryna powinna uzyskać ocenę A lub A+. Wszystko, co powoduje niższą ocenę, traktuj jako błąd. Bądź czujny, ponieważ stale pojawiają się nowe ataki na algorytmy i protokoły.
Ustawianie względnych adresów URL wewnątrz witryny
Teraz, gdy witryna jest dostępna zarówno w protokołach HTTP, jak i HTTPS, musi działać jak najpłynniej niezależnie od protokołu. Ważnym czynnikiem jest używanie adresów URL względnych w przypadku linków wewnątrz witryny.
Upewnij się, że adresy URL wewnątrz witryny i adresy URL zewnętrzne nie zależą od konkretnego protokołu.
Użyj ścieżek względnych lub pomiń protokół, jak w //example.com/something.js.
Przekazywanie strony zawierającej zasoby HTTP za pomocą HTTPS może powodować problemy. Gdy przeglądarka napotka zabezpieczoną stronę, która korzysta z niezabezpieczonych zasobów, ostrzega użytkowników, że strona nie jest w pełni bezpieczna. Niektóre przeglądarki odmawiają wczytywania lub wykonywania zasobów HTTP, co powoduje błąd strony. Możesz jednak bezpiecznie umieszczać zasoby HTTPS na stronie HTTP. Więcej wskazówek na temat rozwiązywania tych problemów znajdziesz w artykule Rozwiązywanie problemów z mieszanymi treściami.
Klikanie linków do innych stron w witrynie może też spowodować przejście z protokołu HTTPS na HTTP. Aby to naprawić, uczyń adresy URL wewnątrz witryny jak najbardziej względnymi, tworząc je jako zależne od protokołu (bez protokołu, zaczynające się od //example.com) lub zależne od hosta (rozpoczynające się od samej ścieżki, np. /jquery.js).
<h1>Welcome To Example.com</h1> <script src="/jquery.js"></script> <link rel="stylesheet" href="/assets/style.css"/> <img src="/images/logo.png"/>; <p>A <a href="/2014/12/24">new post on cats!</a></p>
<h1>Welcome To Example.com</h1> <script src="//example.com/jquery.js"></script> <link rel="stylesheet" href="//assets.example.com/style.css"/> <img src="//img.example.com/logo.png"/>; <p>A <a href="//example.com/2014/12/24/">new post on cats!</a></p>
<h1>Welcome To Example.com</h1> <script src="/jquery.js"></script> <link rel="stylesheet" href="/assets/style.css"/> <img src="/images/logo.png"/>; <p>A <a href="/2014/12/24">new post on cats!</a></p> <p>Check out this <a href="https://foo.com/"><b>other cool site.</b></a></p>
Aby uniknąć pomyłek, aktualizuj linki za pomocą skryptu, a nie ręcznie. Jeśli treści Twojej witryny znajdują się w bazie danych, przetestuj skrypt na kopii deweloperskiej bazy danych. Jeśli zawartość witryny składa się tylko z prostych plików, przetestuj skrypt na kopii rozwojowej plików. Prześlij zmiany do wersji produkcyjnej dopiero wtedy, gdy przejdą kontrolę jakości. Aby wykryć treści mieszane w witrynie, możesz użyć skryptu Brama van Damme lub podobnego.
Jeśli dodajesz linki do innych witryn (a nie wstawiasz w nich zasobów), nie zmieniaj protokołu. Nie masz kontroli nad działaniem tych witryn.
Aby ułatwić migrację dużych witryn, zalecamy stosowanie adresów URL względnych do protokołu. Jeśli nie masz pewności, czy możesz wdrożyć protokół HTTPS, wymuszenie korzystania z niego we wszystkich zasobach podrzędnych może przynieść odwrotny skutek. Prawdopodobnie będzie taki okres, w którym HTTPS będzie dla Ciebie nowością i będziesz się z nim dopiero oswajać, a witryna w protokole HTTP nadal musi działać tak samo dobrze jak do tej pory. Z czasem ukończysz migrację i zabezpieczysz HTTPS (patrz 2 kolejne sekcje).
Jeśli Twoja witryna korzysta ze skryptów, obrazów lub innych zasobów pochodzących od podmiotów zewnętrznych, takich jak sieć CDN lub jquery.com, masz 2 możliwości:
- W przypadku tych zasobów używaj adresów URL zależnych od protokołu. Jeśli firma zewnętrzna nie używa HTTPS, poproś ją o to. Większość już to robi, w tym jquery.com.
- Przesyłaj zasoby z serwera, który jest pod Twoją kontrolą i obsługuje protokoły HTTP i HTTPS. Jest to często dobry pomysł, ponieważ masz wtedy większą kontrolę nad wyglądem, wydajnością i bezpieczeństwem witryny, a także nie musisz ufać firmie zewnętrznej, która miałaby dbać o bezpieczeństwo Twojej witryny.
Przekierowanie HTTP do HTTPS
Aby poinformować wyszukiwarki, że do Twojej witryny należy uzyskiwać dostęp przez protokół HTTPS, umieść kanoniczny link w nagłówku każdej strony, używając tagów <link rel="canonical" href="https://…"/>.
Włącz ścisłe szyfrowanie transportu i zabezpieczone pliki cookie
W tym momencie możesz „zablokować” używanie protokołu HTTPS:
- Użyj mechanizmu HTTP Strict Transport Security (HSTS), aby uniknąć kosztów przekierowania 301.
- Zawsze ustawiaj w plikach cookie flagę Bezpieczne.
Najpierw użyj Strict Transport Security, aby poinformować klientów, że zawsze powinni łączyć się z Twoim serwerem przez HTTPS, nawet gdy korzystają z odwołania http://. Zapobiega to atakom takim jak SSL Stripping i eliminuje koszty przesyłania danych w obie strony 301 redirect, które zostały włączone w Przekierowaniu HTTP na HTTPS.
Aby włączyć HSTS, skonfiguruj nagłówek Strict-Transport-Security. Na stronie HSTS organizacji OWASP znajdują się linki do instrukcji dotyczących różnych rodzajów oprogramowania serwera.
Większość serwerów internetowych umożliwia dodawanie nagłówków niestandardowych.
Pamiętaj też, aby klienci nigdy nie wysyłali plików cookie (np. do uwierzytelniania lub ustawień witryny) przez HTTP. Jeśli na przykład plik cookie uwierzytelniania użytkownika zostanie odsłonięty w postaci zwykłego tekstu, Twoje gwarancje bezpieczeństwa dotyczące całej sesji użytkownika zostaną zniweczone, nawet jeśli zrobisz wszystko inne.
Aby tego uniknąć, zmień swoją aplikację internetową tak, aby zawsze ustawiała flagę Bezpieczne w plikach cookie, które tworzy. Na tej stronie OWASP znajdziesz informacje o ustawianiu flagi Secure w kilku frameworkach aplikacji. Każda platforma ma sposób na ustawienie flagi.
Większość serwerów WWW udostępnia prostą funkcję przekierowania. Użyj tagu 301 (Moved Permanently), aby wskazać wyszukiwarkom i przeglądarkom, że wersja HTTPS jest kanoniczna, oraz przekieruj użytkowników z wersji HTTP do wersji HTTPS witryny.
Ranking wyników wyszukiwaniaSzukaj w rankingu
Google traktuje protokół HTTPS jako pozytywny wskaźnik jakości wyszukiwania. Google publikuje też przewodnik o przenoszeniu witryny, który pomoże Ci zachować jej pozycję w wyszukiwarce. Bing publikuje też wskazówki dla webmasterów.
Wyniki
Gdy warstwy treści i aplikacji są dobrze dostrojone (więcej informacji znajdziesz w książkach Steve'a Soudersa), pozostałe problemy z wydajnością TLS są zazwyczaj niewielkie w porównaniu z ogólnym kosztem aplikacji. Możesz też zmniejszyć te koszty i amortyzować je. Zasady optymalizacji TLS znajdziesz w książce High Performance Browser Networking autorstwa Ilya Grigorik, a także w książce OpenSSL Cookbook i artykule Bulletproof SSL And TLS.
W niektórych przypadkach TLS może poprawić wydajność, głównie dzięki umożliwieniu korzystania z HTTP/2. Więcej informacji znajdziesz w prezentacji Chrisa Palmera na temat wydajności HTTPS i HTTP/2 na konferencji Chrome Dev Summit 2014.
Nagłówki referrera
Gdy użytkownicy klikają linki z Twojej witryny HTTPS do innych witryn HTTP, ich przeglądarki nie wysyłają nagłówka Referer. Jeśli jest to problem, możesz rozwiązać go na kilka sposobów:
- Pozostałe witryny powinny zostać przeniesione na protokół HTTPS. Jeśli witryny referencyjne wypełnią sekcję Włączanie HTTPS na serwerach w tym przewodniku, możesz zmienić w swojej witrynie linki z
http://nahttps://lub użyć linków zależnych od protokołu. - Aby obejść różne problemy z nagłówkami Referer, użyj nowego standardu zasad dotyczących strony odsyłającej.
Przychody z reklam
Operatorzy witryn, którzy zarabiają na wyświetlaniu reklam, chcą mieć pewność, że przejście na protokół HTTPS nie spowoduje spadku liczby wyświetleń reklam. Ze względu na obawy dotyczące bezpieczeństwa treści <iframe> w przypadku strony HTTP nie działa na stronie HTTPS.
Dopóki reklamodawcy nie zaczną publikować treści w protokole HTTPS, operatorzy witryn nie będą mogli przejść na HTTPS bez utraty przychodów z reklam. Dopóki operatorzy witryn nie przejdą na HTTPS, reklamodawcy nie będą mieli zbytniej motywacji do publikowania treści w tym protokole.
Aby przełamać tę impasową sytuację, możesz zacząć korzystać z usług reklamowych przez HTTPS oferowanych przez reklamodawców i poprosić reklamodawców, którzy w ogóle nie wyświetlają reklam przez HTTPS, o ustawienie tej opcji jako opcjonalnej. Możesz odłożyć wykonanie opcji Ustaw względne adresy URL w witrynie do czasu, gdy wystarczająca liczba reklamodawców będzie współpracować prawidłowo.