Włączanie protokołu HTTPS na swoich serwerach

Chris Palmer
Chris Palmer

Na tej stronie znajdziesz wskazówki dotyczące konfigurowania protokołu HTTPS na Twoich serwerach, m.in.:

  • Tworzenie 2048-bitowej pary kluczy publiczny/prywatny RSA.
  • Generowanie żądania podpisania certyfikatu, które zawiera Twój klucz publiczny.
  • udostępnienie przedstawiciela obsługi klienta urzędowi certyfikacji (CA) w celu uzyskania ostatecznego certyfikatu lub łańcucha certyfikatów.
  • Zainstalowanie końcowego certyfikatu w miejscu niedostępnym przez internet, takim jak /etc/ssl (Linux i Uniks) lub wszędzie tam, gdzie jest to wymagane przez IIS (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. Służy on do generowania kluczy prywatnych i publicznych oraz żądania podpisania certyfikatu.

Generowanie pary kluczy (publicznego/prywatnego)

Aby rozpocząć, wygeneruj 2048-bitową parę kluczy RSA. Krótszy klucz może zostać uszkodzony na podstawie ataków brute-force, a dłuższe – z wykorzystaniem zbędnych zasobów.

Do wygenerowania pary kluczy RSA użyj następującego polecenia:

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

Uzyskane dane wyjściowe:

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

Wygeneruj żądanie podpisania certyfikatu

Na tym etapie umieścisz swój klucz publiczny oraz informacje o organizacji i witrynie w żądaniu podpisania certyfikatu lub żądaniu podpisania certyfikatu. Polecenie openssl prosi o podanie wymaganych metadanych.

Uruchomienie tego polecenia:

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 wymagają przesyłania żądań podpisania do nich w różny sposób. Można to zrobić za pomocą formularza na stronie lub wysłać przedstawiciela obsługi klienta e-mailem. Niektóre urzędy certyfikacji lub ich sprzedawcy mogą nawet zautomatyzować całość lub część tego procesu, w tym w niektórych przypadkach pary kluczy i generowanie żądań podpisania certyfikatu.

Wyślij przedstawiciela obsługi klienta do swojego 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 korzystanie z usługi uwierzytelniania za klucz publiczny.

Dostępne są też opcje mapowania klucza na kilka nazw DNS, w tym kilka różnych nazw (np. wszystkie nazwy example.com, www.example.com, example.net i www.example.net) lub nazwy wieloznaczne, takie jak *.example.com.

Skopiuj certyfikaty do wszystkich serwerów frontendu w miejscu niedostępnym z internetu, takim jak /etc/ssl (Linux i Uniks) lub wszędzie tam, gdzie jest to wymagane przez 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 konfiguracji serwera Mozilla, aby skonfigurować serwer pod kątem obsługi protokołu HTTPS.
  • Regularnie testuj witrynę za pomocą testu serwera SSL oferowanego przez firmę Qualys, aby uzyskać co najmniej wynik A lub A+.

W tym momencie musisz podjąć kluczową decyzję w sprawie operacji. Wybierz jedną z tych opcji:

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

Jeśli dla każdej nazwy hosta używasz osobnych adresów IP, możesz obsługiwać zarówno protokół HTTP, jak i HTTPS dla wszystkich klientów. Większość operatorów witryn korzysta jednak z hostingu wirtualnego na podstawie nazw, aby oszczędzać adresy IP i ponieważ jest to zwykle wygodniejsze rozwiązanie.

Jeśli usługa HTTPS nie jest jeszcze dostępna na Twoich serwerach, włącz ją teraz (bez przekierowania HTTP do HTTPS, Więcej informacji znajdziesz w sekcji Przekierowywanie z HTTP do HTTPS. Skonfiguruj serwer WWW, 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 przez cały okres użytkowania witryny sprawdzaj konfigurację HTTPS za pomocą narzędzia Qualys's SSL Server Test. Twoja witryna powinna uzyskać ocenę A lub A+. Traktuj wszystko, co ma niższą ocenę, jako błąd. Zachowaj szczególną ostrożność, bo cały czas pojawiają się nowe ataki na algorytmy i protokoły.

Określ względne adresy URL wewnątrz witryny

Teraz gdy obsługujesz witryny zarówno przy użyciu protokołów HTTP, jak i HTTPS, wszystko musi działać płynnie niezależnie od protokołu. Ważnym czynnikiem jest użycie względnych adresów URL w linkach w witrynie.

Upewnij się, że wewnętrzne adresy URL i zewnętrzne adresy URL nie zależą od konkretnego protokołu. Użyj ścieżek względnych lub pomiń protokół, jak w //example.com/something.js.

Wyświetlanie strony zawierającej zasoby HTTP przy użyciu protokołu HTTPS może powodować problemy. Gdy przeglądarka natrafi na inną zabezpieczoną stronę korzystającą z niezabezpieczonych zasobów, ostrzega użytkowników, że nie jest ona całkowicie bezpieczna, a niektóre przeglądarki odmawiają wczytania lub wykonania zasobów HTTP, co spowoduje uszkodzenie strony. Możesz jednak bezpiecznie umieścić zasoby HTTPS na stronie HTTP. Więcej wskazówek, jak rozwiązać te problemy, znajdziesz w artykule Naprawianie treści mieszanych.

Korzystanie z linków HTTP do innych stron w witrynie również może obniżyć komfort użytkowników z protokołu HTTPS do HTTP. Aby rozwiązać ten problem, zadbaj o możliwie względne, względne adresy URL stron w witrynie – 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 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ć wewnętrznych adresów URL 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 HTTPS jako linków do innych witryn.

Aktualizuj linki za pomocą skryptu, a nie ręcznie, aby uniknąć błędów. Jeśli treść witryny znajduje się w bazie danych, przetestuj skrypt na jej deweloperskiej wersji. Jeśli treść witryny składa się tylko z prostych plików, przetestuj skrypt na wersji deweloperskiej tych plików. Przekaż zmiany do produkcji dopiero wtedy, gdy przejdą kontrolę jakości, jak zwykle. Aby wykryć w witrynie treści mieszane, możesz użyć skryptu Barma van Damme'a lub podobnego rozwiązania.

Podczas tworzenia linków do innych witryn (w odróżnieniu od dodawania z nich zasobów) nie zmieniaj protokołu. Nie masz kontroli nad działaniem tych witryn.

Aby usprawnić migrację w przypadku 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 użycia protokołu HTTPS w witrynie dla wszystkich zasobów podrzędnych może się nie udać. Być może zapewne w pewnym czasie protokół HTTPS jest dla Ciebie czymś nowym i dziwnym, a witryna HTTP musi nadal działać tak samo dobrze. Z czasem zakończysz migrację i zablokujesz protokół HTTPS (zapoznaj się z 2 kolejnymi sekcjami).

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

  • W przypadku 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ść już tak ma, w tym jquery.com.
  • Wyświetlaj zasoby z kontrolowanego przez Ciebie serwera, który obsługuje zarówno protokoły HTTP, jak i HTTPS. I tak często jest to dobry pomysł, ponieważ dzięki temu masz większą kontrolę nad wyglądem, wydajnością i bezpieczeństwem swojej witryny oraz nie musisz ufać innym firmom, które będą chronić Twoją witrynę.

Przekieruj z HTTP do HTTPS

Aby umożliwić wyszukiwarkom dostęp do Twojej witryny za pomocą protokołu HTTPS, umieść link kanoniczny w nagłówku każdej strony za pomocą tagów <link rel="canonical" href="https://…"/>.

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

Teraz możesz już „zablokować” korzystanie z protokołu HTTPS:

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

Po pierwsze użyj zasady Strict Transport Security, aby poinformować klientów, że zawsze powinni łączyć się z Twoim serwerem przy użyciu protokołu HTTPS, nawet jeśli korzystają z odwołania http://. Pozwala to powstrzymać ataki takie jak usunięcie SSL i uniknąć kosztu ruchu w obie strony 301 redirect włączonych w opcji Przekierowanie HTTP do HTTPS.

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

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

Ważne jest też, aby klienci nigdy nie wysyłali 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 ujawniony w postaci zwykłego tekstu, gwarancja bezpieczeństwa dla całej sesji zostanie zniszczona, nawet jeśli wszystko zostało zrobione prawidłowo.

Aby tego uniknąć, zmień aplikację internetową tak, aby zawsze ustawiała flagę Secure w ustawionych przez nią plikach cookie. Na tej stronie OWASP wyjaśniono, jak ustawić flagę Secure w kilku platformach aplikacji. Każda platforma aplikacji ma swój sposób oznaczenia.

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

Ranking wyników wyszukiwaniaSzukaj w rankingu

Google używa HTTPS jako pozytywnego wskaźnika jakości wyszukiwania. Google publikuje również przewodnik o przenoszeniu, przenoszeniu i migracji witryny przy zachowaniu jej pozycji w wynikach wyszukiwania. Bing publikuje również wytyczne dla webmasterów.

Występy

Gdy treść i warstwy aplikacji są dobrze dostrojone (zalecenia znajdziesz w książkach Steve'a Soudersa), pozostałe problemy z wydajnością TLS są na ogół niewielkie w porównaniu z ogólnym kosztem aplikacji. Możesz także zmniejszyć i amortyzować te koszty. Wskazówki dotyczące optymalizacji TLS znajdziesz w dokumentach High Performance Browser Networking (Sieć o wysokiej wydajności przeglądarki) autorstwa Ilyi Grigorik, a także w publikacjach Ivana Rists Poradnika OpenSSL Cookbook i Bullet daną w zakresie protokołu SSL i TLS.

W niektórych przypadkach protokół TLS może zwiększyć wydajność, głównie ze względu na obsługę protokołu HTTP/2. Więcej informacji znajdziesz w przemówieniu Chrisa Palmera na temat wydajności protokołu HTTPS i HTTP/2 na konferencji Chrome Dev Summit 2014.

Nagłówki strony odsyłającej

Gdy użytkownicy przechodzą 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:

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 mieszanej, <iframe> HTTP nie działa na stronie HTTPS. Dopóki reklamodawcy nie zaczną publikować przez HTTPS, operatorzy witryn nie będą mogli przejść na HTTPS bez utraty przychodów z reklam. Jednak dopóki operatorzy witryn nie zaczną korzystać z HTTPS, ich motywacja do stosowania protokołu HTTPS nie będzie zbyt duża.

Możesz rozpocząć proces eliminacji tego problemu, kontaktując się z reklamodawcami oferującymi usługi reklamowe przez HTTPS i poproś reklamodawców, którzy w ogóle nie korzystają z protokołu HTTPS, o to, by skorzystali z tej możliwości. Być może trzeba będzie odroczyć proces uaktualniania adresów URL w witrynie do momentu, gdy wystarczająca liczba reklamodawców będzie prawidłowo współpracować.