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

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ć 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ć 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żdego hosta, z którego serwer WWW dostarcza treści.
Użyj wirtualnego hostingu opartego na nazwie.

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 powstają 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 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 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 w witrynie 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ętrznych 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 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 na stronie korzystania z protokołu HTTPS w przypadku wszystkich zasobów 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 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 witrynę za pomocą 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 zewnętrzna firma 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. 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 otwierania witryny należy używać protokołu 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 „zablokować” 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ę Bezpieczne.

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. 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 przekierować użytkowników z wersji HTTP do wersji HTTPS Twojej witryny.

Ranking wyników wyszukiwaniaSzukaj w rankingu

Google traktuje protokół HTTPS jako pozytywny wskaźnik jakości wyszukiwania. Google publikuje też przewodnik jak przenieść witrynę, zachowując jej pozycję w wynikach wyszukiwania. Bing publikuje też wytyczne 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 stosunku do ogólnych kosztów aplikacji. Możesz też zmniejszyć te koszty i amortyzować je. Porady dotyczące 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.

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 czynności Ustaw względne adresy URL w witrynie do czasu, gdy wystarczająca liczba reklamodawców będzie współpracować prawidłowo.