Ta strona została przetłumaczona przez Cloud Translation API.

Włączanie protokołu HTTPS na swoich serwerach

Chris Palmer

Matt Gaunt

Na tej stronie znajdziesz wskazówki dotyczące konfigurowania protokołu HTTPS na serwerach, w tym te czynności:

Tworzenie pary kluczy publicznego i prywatnego RSA o długości 2048 bitów.
Generowanie żądania podpisania certyfikatu (CSR) zawierającego 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).

Generowanie kluczy i żądań podpisania certyfikatów

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 (publiczny i prywatny)

Najpierw wygeneruj 2048-bitową parę kluczy RSA. 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

Otrzymasz taki wynik:

Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)

Generowanie żądania podpisania certyfikatu

W tym kroku musisz umieścić klucz publiczny oraz informacje o swojej 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ć poprawność żądania podpisania certyfikatu, 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 żądań podpisania certyfikatu na różne sposoby. Może to być formularz na stronie internetowej lub e-mail do zespołu obsługi klienta. 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 na kilka różnych nazw (np.wszystkie z example. com, www.example.com, example.net i www.example.net) lub na nazwy „symbol wieloznacznych”, 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żdego hosta, z którego serwer WWW dostarcza 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 nie masz jeszcze usługi HTTPS dostępnej na Twoich serwerach, włącz ją teraz (bez przekierowania HTTP do HTTPS. Więcej informacji znajdziesz w sekcji Przekierowanie HTTP do HTTPS. Skonfiguruj serwer WWW tak, aby używał zakupionych i zainstalowanych certyfikatów. Może Ci się przydać generator 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 na stronie

Teraz gdy udostępniasz witrynę zarówno przy użyciu protokołu HTTP, jak i HTTPS, wszystko powinno działać płynnie, niezależnie od protokołu. Ważnym czynnikiem jest używanie względnych adresów URL 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.

Przesyłanie 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 dotyczących rozwiązywania tych problemów znajdziesz w artykule Naprawianie treści mieszanych.

Linki oparte na protokole HTTP prowadzące do innych stron w Twojej witrynie mogą też obniżyć poziom wygody użytkowników z 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).

Tak

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

Używaj względnych adresów URL w witrynie.

Tak

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

Możesz też użyć adresów URL wewnątrz witryny zależnych od protokołu.

Tak

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

W miarę możliwości używaj adresów URL protokołu HTTPS w przypadku linków do innych witryn.

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 migracja przebiegła bezproblemowo w przypadku dużych witryn, zalecamy stosowanie adresów URL zależnych od protokołu. Jeśli nie masz jeszcze pewności, czy możesz w pełni wdrożyć protokół HTTPS, wymuszenie w witrynie używania HTTPS we wszystkich zasobach podrzędnych może się nie powieść. Prawdopodobnie będzie taki okres, w którym HTTPS będzie dla Ciebie nowością i będziesz się z nim dopiero oswajać, a w tym czasie witryna w protokole HTTP musi nadal 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 podmiotu zewnętrznego, np. z 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 obsługuje 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. Często jest to dobry pomysł, ponieważ zapewnia większą kontrolę nad wyglądem, wydajnością i bezpieczeństwem witryny oraz nie wymaga zaufania do innych firm w ochronie 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 rygorystyczne zabezpieczenia transportu i zabezpiecz pliki cookie

Teraz możesz „zgodzić się” na korzystanie z protokołu HTTPS:

Użyj mechanizmu HTTP Strict Transport Security (HSTS), aby uniknąć kosztów przekierowania 301.
Zawsze ustawiaj w plikach cookie flagę Bezpieczeństwo.

Najpierw użyj Strict Transport Security, aby poinformować klientów, że zawsze powinni łączyć się z Twoim serwerem przez HTTPS, nawet jeśli korzystają z odwołania http://. Zapobiega to atakom takim jak SSL Stripping i eliminuje koszty przekierowań 301 redirect, które zostały włączone w przekierowaniu HTTP na HTTPS.

Aby włączyć HSTS, skonfiguruj nagłówek Strict-Transport-Security. Strona HSTS na stronie OWASP zawiera linki do instrukcji dotyczących różnych rodzajów oprogramowania serwerowego.

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ą, 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 oferuje prostą funkcję przekierowania. Użyj tagu 301 (Moved Permanently), aby wskazać wyszukiwarkom i przeglądarkom, że wersja HTTPS jest kanoniczna, oraz przekierować użytkowników z wersji HTTP do wersji HTTPS Twojej witryny.

Ranking wyników wyszukiwaniaSzukaj w rankingu

Google używa HTTPS jako wskaźnika pozytywnej jakości wyszukiwania. Google publikuje też przewodnik jak przenieść witrynę, zachowując jej pozycję w wynikach wyszukiwania. 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ólnymi kosztami 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 protokół TLS może poprawić wydajność, głównie dzięki umożliwieniu korzystania z protokołu 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 go rozwiązać na kilka sposobów:

Pozostałe witryny powinny zostać przeniesione na 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:// na https:// 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 będą 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 motywacji do publikowania treści w tym protokole.

Proces ten można rozpocząć od skorzystania z pomocy reklamodawców, którzy oferują usługi reklamowe przez HTTPS, i zapytania reklamodawców, którzy w ogóle nie obsługują HTTPS, by przynajmniej zrobili to w ramach tej opcji. 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.