Włączanie protokołu HTTPS na serwerach

Krzysztof Palmer
Chris Palmer

Czynności opisane w tym artykule

  1. Utwórz 2048-bitową parę kluczy publiczny/prywatny RSA.
  2. Wygeneruj żądanie podpisania certyfikatu, które umieści Twój klucz publiczny.
  3. Udostępnij swojemu urzędowi certyfikacji (CA), aby uzyskać końcowy certyfikat lub łańcuch certyfikatów.
  4. Zainstaluj ostateczny certyfikat w miejscu niedostępnego z internetu, takim jak /etc/ssl (Linux i Unikx), lub wszędzie tam, gdzie IIS go wymaga (Windows).

Generowanie kluczy i żądań podpisania certyfikatów

W tej sekcji używany jest program wiersza poleceń opensl, który jest dostępny w większości systemów Linux, BSD i Mac OS X, aby wygenerować klucze prywatne/publiczne i żądanie podpisania certyfikatu.

Generowanie pary kluczy (publicznego/prywatnego)

Zacznijmy od wygenerowania 2048-bitowej pary kluczy RSA. Mniejszy klucz, np. 1024 bity, nie jest wystarczająco odporny na ataki typu brute-force. Większy klucz, np. 4096 bitów, jest metodą overkill. Z czasem rozmiary kluczy będą się zwiększać, bo przetwarzanie przez komputer staje się tańsze. Optymalny wynik to 2048.

Polecenie do wygenerowania pary kluczy RSA to:

openssl genrsa -out www.example.com.key 2048

Uzyskane wyniki:

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

Generowanie żądania podpisania certyfikatu

W tym kroku umieścisz klucz publiczny oraz informacje o organizacji i witrynie w żądaniu podpisania certyfikatu lub w żądaniu podpisania certyfikatu. Polecenie openssl interaktywnie prosi o podanie wymaganych metadanych.

Uruchamiam to polecenie:

openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr

Generuje:

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ą różnych metod wysyłania żądań podpisania certyfikatu. Może to być między innymi przesłanie formularza obsługi klienta e-mailem lub wypełnienie formularza w witrynie. Niektóre urzędy certyfikacji (lub ich sprzedawcy) mogą nawet zautomatyzować cały proces lub część tego procesu (w tym w niektórych przypadkach pary kluczy i generowanie żądań podpisania certyfikatu).

Wyślij żądanie podpisania certyfikatu do urzędu certyfikacji i postępuj zgodnie z jego instrukcjami, aby otrzymać końcowy certyfikat lub łańcuch certyfikatów.

Różne urzędy certyfikacji pobierają różne kwoty za usługę ręczności za klucz publiczny.

Dostępne są też opcje mapowania klucza na więcej niż 1 nazwę DNS, w tym do kilku różnych nazw (np.wszystkie nazwy example. com, www.example.com, example.net i www.example.net) lub nazwy „symbolicznej”, np. *.example.com.

Na przykład jeden urząd certyfikacji oferuje obecnie takie ceny:

  • Standardowa: 16 USD/rok (oferta ważna w przypadku domen example.com i www.example.com).
  • Symbol wieloznaczny: 150 USD/rok – obowiązuje w przypadku domen example.com i *.example.com.

W tych cenach certyfikaty z symbolami wieloznacznymi są ekonomiczne, jeśli masz więcej niż 9 subdomen. W przeciwnym razie możesz kupić co najmniej 1 certyfikat z jedną nazwą. Jeśli masz więcej niż, np. 5 subdomen, włączenie protokołu HTTPS na swoich serwerach może być dla Ciebie wygodniejsze.

Skopiuj certyfikaty do wszystkich serwerów interfejsu użytkownika w miejscu niedostępnym przez internet, takim jak /etc/ssl (Linux i Unix) lub tam, gdzie wymaga ich IIS (Windows).

Włączanie protokołu HTTPS na swoich serwerach

Włączenie protokołu HTTPS na serwerach ma kluczowe znaczenie dla zapewnienia bezpieczeństwa Twoich stron internetowych.

  • Użyj narzędzia Mozilla Server Configuration (Konfiguracja serwera) w programie Mozilla, aby skonfigurować serwer pod kątem obsługi protokołu HTTPS.
  • Regularnie testuj swoją witrynę za pomocą dostępnego w Qualys testu serwera SSL, aby uzyskać co najmniej A lub A+.

Na tym etapie musisz podjąć kluczową decyzję związaną z operacją. Wybierz jedną z tych opcji:

  • Do każdej nazwy hosta, z której Twój serwer WWW wyświetla treści, przypisz osobny adres IP.
  • Użyj hostingu wirtualnego na podstawie nazwy.

Jeśli dla każdej nazwy hosta używasz różnych adresów IP, możesz z łatwością obsługiwać zarówno HTTP, jak i HTTPS dla wszystkich klientów.

Jednak większość operatorów witryn korzysta z hostingu wirtualnego na podstawie nazw, aby oszczędzać adresy IP, a także dlatego, że jest to wygodniejsze rozwiązanie. Problem w IE w wersjach systemu Windows XP i starszych niż 2.3 polega na tym, że usługa Server Name Indication (SNI) nie rozumie – jest to niezbędne dla hostingu wirtualnego opartego na nazwach HTTPS.

Klienty, które nie obsługują SNI, zostaną kiedyś zastąpione nowoczesnymi. Monitoruj ciąg znaków klienta użytkownika w dziennikach żądań, aby wiedzieć, kiedy wystarczająca liczba użytkowników została przeniesiona do nowoczesnego oprogramowania. Możesz wybrać wartość progową, która może być mniejsza niż 5% lub mniejsza niż 1%.

Jeśli nie masz jeszcze dostępnej usługi HTTPS na swoich serwerach, włącz ją teraz (bez przekierowania HTTP do HTTPS – patrz niżej). Skonfiguruj serwer WWW, aby używał kupionych i zainstalowanych certyfikatów. Może Ci się przydać przydatny generator konfiguracji Mozilla.

Jeśli masz wiele nazw hostów lub subdomen, każda z nich musi używać odpowiedniego certyfikatu.

Teraz, przez cały okres istnienia witryny, sprawdzaj konfigurację HTTPS za pomocą narzędzia Qualys ds. testowania serwera SSL. Twoja witryna powinna uzyskać ocenę A lub A+. Wszystko, co powoduje obniżenie oceny, należy traktować jako błąd. (Dziś A to jutro B, bo ataki na algorytmy i protokoły stale się poprawiają!)

Ustaw względne adresy URL wewnątrz witryny

Gdy udostępniasz witrynę zarówno za pomocą protokołu HTTP, jak i HTTPS, wszystko musi działać płynnie, niezależnie od protokołu. Ważnym czynnikiem jest używanie względnych adresów URL w przypadku linków w witrynie.

Zadbaj o to, aby adresy URL wewnątrz witryny i zewnętrzne adresy URL były niezależne od protokołu. Oznacza to, że użyj ścieżek względnych lub pomiń protokół taki jak //example.com/something.js.

Problem pojawia się, gdy przez protokół HTTPS udostępniasz stronę, która zawiera zasoby HTTP, czyli tzw. treści mieszaną. Przeglądarki ostrzegają użytkowników, że w pełni wykorzystaliśmy protokół HTTPS. W przypadku aktywnej treści mieszanej (skrypty, wtyczki, CSS, elementy iframe) przeglądarki często po prostu w ogóle nie wczytują ani nie wykonują treści, co skutkuje uszkodzeniem strony. Pamiętaj, że umieszczenie zasobów HTTPS na stronie HTTP jest prawidłowe.

Jeśli dodasz linki do innych stron w witrynie, użytkownicy mogą przejść z protokołu HTTPS do HTTP.

Takie problemy występują, gdy strony zawierają w pełni kwalifikowane adresy URL wewnątrz witryny korzystające ze schematu http://.

Nie
<h1>Welcome To Example.com</h1>
<script src="http://example.com/jquery.js"></script>
<link rel="stylesheet" href="http://assets.example.com/style.css"/>
<img src="http://img.example.com/logo.png"/>;
<p>A <a href="http://example.com/2014/12/24/">new post on cats!</a></p>
Unikaj korzystania z pełnych i jednoznacznych adresów URL w witrynie.

Innymi słowy, adresy URL w witrynie powinny być jak najbardziej względne: zależne od protokołu (bez protokołu, zaczynając od //example.com) lub od hosta (zaczynają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 wewnątrz witryny.
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ć wewnątrz witryny zależnych od protokołu adresów URL.
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 HTTPS w przypadku adresów URL między witrynami.

Zrób to za pomocą skryptu, a nie ręcznie. Jeśli zawartość witryny znajduje się w bazie danych, przetestuj skrypt na kopii programistycznej bazy danych. Jeśli zawartość witryny składa się z prostych plików, przetestuj skrypt na podstawie wersji roboczej plików. Przekaż zmiany do produkcji dopiero wtedy, gdy przejdą kontrolę jakości, tak jak zwykle. Aby wykryć w swojej witrynie treści o różnych ustawieniach, możesz użyć skryptu Barma van Damme lub podobnego.

Gdy zamieszczasz linki do innych witryn (zamiast dodawać pochodzące z nich zasoby), nie zmieniaj protokołu, ponieważ nie masz kontroli nad działaniem tych witryn.

Aby usprawnić migrację dużych witryn, zalecamy adresy URL zależne od protokołu. Jeśli nie masz pewności, czy możesz jeszcze w pełni wdrożyć protokół HTTPS, wymuszenie stosowania protokołu HTTPS w witrynie dla wszystkich zasobów podrzędnych może nie zostać zrealizowane. Być może za jakiś czas protokół HTTPS stanie się czymś nowym i dziwnym, a witryna HTTP będzie musiała działać tak samo jak dotychczas. Z czasem zakończysz migrację i zablokujesz protokół HTTPS (zapoznaj się z 2 następnymi sekcjami).

Jeśli Twoja witryna zależy od skryptów, obrazów lub innych zasobów udostępnianych przez firmę zewnętrzną, np. CDN lub jquery.com, masz 2 możliwości:

  • Dla tych zasobów użyj adresów URL zależnych od protokołu. Jeśli firma zewnętrzna nie obsługuje protokołu HTTPS, poproś ją o to. Większość z nich już korzysta, w tym jquery.com.
  • Udostępniaj zasoby z kontrolowanego przez Ciebie serwera, który obsługuje protokoły HTTP i HTTPS. Często i tak jest to dobry pomysł, ponieważ masz większą kontrolę nad wyglądem, wydajnością i bezpieczeństwem witryny. Nie trzeba też ufać zewnętrznej firmie, co zawsze jest miłe.

Przekieruj z HTTP do HTTPS

W nagłówku strony musisz umieścić link kanoniczny, aby poinformować wyszukiwarki, że najlepszym sposobem na otwarcie witryny jest HTTPS.

Ustaw tagi <link rel="canonical" href="https://…"/> na swoich stronach. Pomaga to wyszukiwarkom określić najlepszy sposób dotarcia do Twojej witryny.

Włączanie Strict Transport Security i bezpiecznych plików cookie

Na tym etapie możesz zacząć „blokować się” w korzystaniu z protokołu HTTPS.

  • Używaj HSTS (HTTP Strict Transport Security), aby uniknąć kosztów przekierowania 301.
  • Zawsze ustawiaj flagę Bezpieczne dla plików cookie.

Po pierwsze, użyj zasady Strict Transport Security, aby poinformować klientów, że powinni zawsze łączyć się z Twoim serwerem przez HTTPS, nawet jeśli przestrzegają odniesienia do http://. Pozwala to powstrzymać ataki, takie jak usunięcie protokołu SSL, oraz zmniejszyć koszt łącza w obie strony typu 301 redirect w ramach opcji Przekierowanie HTTP do HTTPS.

Włącz HSTS (HTTP Strict Transport Security), ustawiając nagłówek Strict-Transport-Security. Strona HSTS na stronie OWASP zawiera linki do instrukcji dotyczących różnych programów serwerowych.

Większość serwerów WWW oferuje podobną możliwość dodawania niestandardowych nagłówków.

Ważne jest też, aby upewnić się, że klienci nigdy nie wysyłają plików cookie (np. w celu uwierzytelniania lub określania ustawień witryny) przez HTTP. Jeśli na przykład plik cookie uwierzytelniania użytkownika zostanie otwarty w postaci zwykłego tekstu, gwarancja bezpieczeństwa całej sesji użytkownika zostanie zniszczona – nawet jeśli wszystko inne zostało wykonane prawidłowo.

Dlatego zmień aplikację internetową tak, aby zawsze ustawiała flagę Secure w utworzonych przez nią plikach cookie. Na tej stronie OWASP wyjaśniono, jak ustawić flagę Secure w kilku platformach aplikacji. Każda platforma aplikacji ma sposób ustawiania flagi.

Większość serwerów WWW udostępnia prostą funkcję przekierowania. Użyj elementu 301 (Moved Permanently), aby wskazać wyszukiwarkom i przeglądarkom, że wersja HTTPS jest kanoniczna, i przekierować użytkowników z HTTP do wersji HTTPS witryny.

Ranking wyników wyszukiwaniaSzukaj w rankingu

Google używa HTTPS jako pozytywnego wskaźnika jakości wyszukiwania. Google publikuje również przewodniki dotyczące przenoszenia, przenoszenia i migracji witryny przy zachowaniu jej pozycji w rankingu. Bing publikuje też wskazówki dla webmasterów.

Występy

Gdy zawartość i warstwy aplikacji są dobrze dostrojone (zalecenie znajdziesz w książkach Steve'a Soudersa), pozostałe problemy z wydajnością TLS są zwykle niewielkie w stosunku do ogólnego kosztu aplikacji. Możesz też obniżyć i amortyzować te koszty. Przydatne porady na temat optymalizacji TLS (i ogólnie) znajdziesz w artykule Ilya Grigorik High Performance Browser Networking (Sieć przeglądarki o wysokiej wydajności). Zapoznaj się też z publikacjami Ivana Ristics OpenSSL Cookbook i Bulletdostęp SSL and TLS.

W niektórych przypadkach protokół TLS może poprawić wydajność, głównie dzięki temu, że umożliwia korzystanie z protokołu HTTP/2. Chris Palmer wygłosił prezentację na temat wydajności HTTPS i HTTP/2 na konferencji Chrome Dev Summit 2014.

Nagłówki strony odsyłającej

Gdy użytkownicy klikają linki z Twojej witryny HTTPS do innych witryn HTTP, klienty użytkownika nie wysyłają nagłówka strony odsyłającej. Jeśli jest to problem, można go rozwiązać na kilka sposobów:

Ze względu na to, że wyszukiwarki przechodzą na HTTPS w przyszłości, po przejściu na HTTPS prawdopodobnie zobaczysz więcej nagłówków stron odsyłających.

Przychody z reklam

Operatorzy witryn, którzy zarabiają na wyświetlaniu reklam, chcą mieć pewność, że przejście na protokół HTTPS nie zmniejszy liczby wyświetleń reklam. Jednak ze względu na problemy z bezpieczeństwem treści o różnych ustawieniach SSL <iframe> HTTP nie działa na stronie HTTPS. Istnieje tu problem zbiorowego działania zbiorowego: dopóki reklamodawcy nie publikują przez HTTPS, operatorzy witryn nie mogą przejść na HTTPS bez utraty przychodów z reklam; ale dopóki operatorzy witryn nie przejdą na HTTPS, reklamodawcy nie będą się motywować do stosowania HTTPS.

Reklamodawcy powinni oferować przynajmniej korzystanie z usługi reklamowej poprzez protokół HTTPS (np. w sekcji „Włącz HTTPS na swoich serwerach” na tej stronie). Wiele osób już tak robi. Trzeba poprosić reklamodawców, którzy w ogóle nie korzystają z protokołu HTTPS, o przynajmniej rozpoczęcie. Możesz odroczyć proces ustawiania adresów URL w witrynie względnych do momentu, gdy wystarczająca liczba reklamodawców będzie prawidłowo współdziałać.