Włączanie protokołu HTTPS na serwerach

Chris Palmer

Matt Gaunt

Twitter Strona główna

Czynności opisane w tym artykule

1. Utwórz 2048-bitową parę kluczy publiczny/prywatny RSA.
2. Wygeneruj żądanie podpisania certyfikatu, które zawiera Twój klucz publiczny.
3. Udostępnij przedstawiciela obsługi klienta urzędowi certyfikacji (CA), aby uzyskać końcowy certyfikat lub łańcuch certyfikatów.
4. Zainstaluj końcowy certyfikat w miejscu niedostępnego z internetu, np. w /etc/ssl (Linux i Unix) lub w miejscach, w których jest wymagany przez IIS (Windows).

Generowanie kluczy i żądań podpisania certyfikatów

W tej sekcji zostanie użyty program do generowania kluczy prywatnych/publicznych oraz żądania podpisania certyfikatu za pomocą programu do obsługi wiersza poleceń opensl, który jest dostępny w większości systemów Linux, BSD i Mac OS X.

Generowanie pary kluczy (publicznego/prywatnego)

Zacznijmy od wygenerowania 2048-bitowej pary kluczy RSA. Mniejszy klucz, np. 1024 bity, jest niewystarczająco odporny na ataki typu brute-force. Większy klucz, na przykład 4096 bitów, jest nadmiarowy. Z czasem rozmiar kluczy rośnie, ponieważ przetwarzanie komputera staje się tańsze. Obecnie optymalnym rozwiązaniem jest 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 swój klucz publiczny oraz informacje o organizacji i witrynie w żądaniu podpisania certyfikatu lub żą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 do nich żądań obsługi klienta. Może to być między innymi wypełnienie formularza na stronie internetowej lub przesłanie zgłoszenia do obsługi klienta e-mailem. Niektóre urzędy certyfikacji (lub ich sprzedawcy) mogą nawet zautomatyzować część lub całość tego procesu (w tym w niektórych przypadkach parę kluczy i generowanie żądań podpisania certyfikatu).

Wyślij tego przedstawiciela do urzędu certyfikacji i postępuj zgodnie z 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 klucza publicznego.

Dostępne są też opcje mapowania klucza na kilka nazw DNS, w tym z kilkoma różnymi nazwami (np. wszystkie domeny example.com, www.example.com, example.com i www.example.net) lub nazwy „wielce”, takie jak *.example.com.

Na przykład jeden z urzędów certyfikacji oferuje obecnie takie ceny:

• Standardowy: 16 USD/rok, ważny w przypadku domen example.com i www.example.com.
• Symbol wieloznaczny: 150 USD/rok, ważny dla domen example.com i *.example.com.

Przy 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 Twoich serwerach może być dla Ciebie wygodniejsze).

Skopiuj certyfikaty do wszystkich serwerów interfejsu w niedostępnym dla internetu miejscu, takim jak /etc/ssl (Linux i Unix) lub tam, gdzie wymaga tego usługa IIS (Windows).

Włączanie protokołu HTTPS na swoich serwerach

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

• Użyj narzędzia konfiguracji serwera Mozilli, aby skonfigurować serwer pod kątem obsługi protokołu HTTPS.
• Regularnie testuj swoją witrynę za pomocą testu serwera SSL oferowanego przez Qualys i upewnij się, że uzyskasz co najmniej A lub A+.

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

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

Jeśli używasz różnych adresów IP dla każdej nazwy hosta, możesz łatwo obsługiwać HTTP 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 dlatego jest to wygodniejsze rozwiązanie. Problem z IE w systemach Windows XP i starszych niż 2.3 polega na tym, że usługa Server Name Indication (SNI) jest niezbędna dla hostingu wirtualnego opartego na nazwach HTTPS.

Klienty, które nie obsługują SNI, zostaną kiedyś zastąpione nowoczesnym oprogramowaniem. Monitoruj ciąg klienta użytkownika w dziennikach żądań, aby wiedzieć, czy dostateczna liczba użytkowników została przeniesiona do nowoczesnego oprogramowania. (Możesz określić, jaki jest Twój próg; może wynosić mniej niż 5% lub mniej niż 1%).

Jeśli usługa HTTPS nie jest jeszcze dostępna na Twoich 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 w Mozilli.

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

Teraz, przez cały okres użytkowania witryny, sprawdź konfigurację HTTPS za pomocą testu serwera SSL oferowanego przez Qualys. Twoja witryna powinna mieć ocenę A lub A+. Wszystko, co powoduje niższą ocenę, należy traktować jako błąd. (Dziś A to jutro B, ponieważ ataki na algorytmy i protokoły są stale usprawniane!)

Ustaw względne adresy URL w witrynie

Teraz 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 linkach w witrynie.

Upewnij się, że adresy URL wewnątrz witryny i zewnętrzne są 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 udostępniasz stronę za pomocą protokołu HTTPS, która zawiera zasoby HTTP, czyli tzw. treści mieszane. Przeglądarki ostrzegają użytkowników, że w pełni wykorzystano potencjał protokołu 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ą jej zawartości, co skutkuje uszkodzeniem strony. Pamiętaj, że na stronie HTTP możesz umieścić zasoby HTTPS.

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

Takie problemy występują, gdy strony zawierają pełne i jednoznaczne umieszczone w witrynie adresy URL, które korzystają ze schematu http://.

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

Inaczej mówiąc, adresy URL w witrynie powinny być jak najbardziej względne: zależne od protokołu (bez protokołu, zaczynając od //example.com) lub zależne od hosta (zaczynają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>

Zrób to za pomocą skryptu, a nie ręcznie. Jeśli treść witryny znajduje się w bazie danych, przetestuj skrypt na jej deweloperskiej bazie danych. Jeśli zawartość witryny składa się z prostych plików, przetestuj swój skrypt na przeznaczonej do tego wersji plików. Przekaż zmiany do wersji produkcyjnej dopiero po przejściu kontroli jakości. Aby wykryć w swojej witrynie treści o mieszanych zabezpieczeniach, możesz użyć skryptu Barma van Damme lub podobnego.

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

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 w witrynie używania protokołu HTTPS dla wszystkich zasobów podrzędnych może się nie udać. Może się zdarzyć, że w pewnym momencie protokół HTTPS stanie się nowy i dziwny, 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 zależy od skryptów, obrazów lub innych zasobów dostarczanych 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ść już używa, w tym jquery.com.
• Wyświetlaj zasoby z kontrolowanego przez Ciebie serwera, który obsługuje protokoły HTTP i HTTPS. Zazwyczaj jest to dobry pomysł, ponieważ daje Ci większą kontrolę nad wyglądem, wydajnością i bezpieczeństwem witryny. Nie trzeba też ufać firmom zewnętrznym, co jest zawsze przyjemne.

Przekieruj z HTTP do HTTPS

Umieść link kanoniczny w nagłówku strony, aby poinformować wyszukiwarki, że najlepszym sposobem na dostęp do Twojej witryny jest protokół HTTPS.

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

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

W tej sytuacji możesz „zablokować” korzystanie z protokołu HTTPS.

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

Najpierw użyj zasady Strict Transport Security, aby poinformować klientów, że zawsze powinni łączyć się z Twoim serwerem przez HTTPS, nawet jeśli są zgodne ze specyfikacją http://. Pozwala to powstrzymać ataki takie jak usunięcie protokołu SSL i uniknąć kosztów komunikacji w obie strony z protokołem 301 redirect, który włączono w opcji Przekierowanie HTTP do HTTPS.

Włącz mechanizm HTTP Strict Transport Security (HSTS), 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 udostępnia podobną możliwość dodawania niestandardowych nagłówków.

Ważne jest też, aby klienci nigdy nie wysyłali plików cookie (na przykład w celu uwierzytelnienia lub ustawień witryny) przez HTTP. Jeśli na przykład plik cookie uwierzytelniania użytkownika zostanie ujawniony w postaci zwykłego tekstu, gwarancja bezpieczeństwa całej jego sesji zostanie zniszczona – nawet jeśli wszystko będzie działać prawidłowo.

Dlatego zmień aplikację internetową tak, by zawsze ustawiała flagę Secure w utworzonych przez nią plikach cookie. Na tej stronie OWASP dowiesz się, jak ustawić flagę bezpiecznej w kilku platformach aplikacji. Każda platforma aplikacji ma sposób na ustawienie flagi.

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ż poradnik dotyczący przenoszenia, przenoszenia i migracji witryny przy zachowaniu jej pozycji w wynikach wyszukiwania. Bing publikuje również wskazówki dla webmasterów.

Występy

Gdy warstwy treści i aplikacji są dobrze dostrojone (zależy to od książek Steve'a Soudersa), pozostałe problemy z wydajnością TLS są na ogół niewielkie w porównaniu z całkowitym kosztem aplikacji. Poza tym możesz obniżyć i amortyzować te koszty. Świetne porady dotyczące optymalizacji TLS i ogólne informacje znajdziesz w artykule High Performance Browser Networking autorstwa Ilyi Grigorik. Zapoznaj się też z książkami OpenSSL Cookbook autorstwa Ivana Risma i bulletbound SSL and TLS.

W niektórych przypadkach protokół TLS może poprawić wydajność, głównie po umożliwieniu korzystania 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 stanowi to problem, można go rozwiązać na kilka sposobów:

• W przypadku pozostałych witryn należy przejść na HTTPS. Jeśli witryna odsyłająca użytkowników zapozna się z sekcją Włączanie HTTPS na swoich serwerach w tym przewodniku, możesz zmienić linki w Twojej witrynie na ich linki z http:// na https:// lub użyć linków zależnych od protokołu.
• Aby rozwiązać różne problemy z nagłówkami stron odsyłających, skorzystaj z nowego standardu zasad dotyczących stron odsyłających.

Wyszukiwarki przechodzą na protokół HTTPS, dlatego w przyszłości po przejściu na ten protokół możesz spodziewać się 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 zabezpieczeniami treści mieszanej, adres <iframe> HTTP nie działa na stronie HTTPS. Istnieje tutaj niejasny problem z zbiorczymi działaniami: dopóki reklamodawcy nie będą publikować przez HTTPS, operatorzy witryn nie mogą przejść na HTTPS bez utraty przychodów z reklam. Dopóki operatorzy witryn nie przejdą na protokół HTTPS, reklamodawcy nie będą prawie zachęcani do używania protokołu HTTPS.

Reklamodawcy powinni oferować usługi reklamowe przynajmniej przez HTTPS (np. wypełniając sekcję „Włącz HTTPS na swoich serwerach” na tej stronie). Wiele już tak. Trzeba poprosić reklamodawców, którzy w ogóle nie korzystają z protokołu HTTPS, o to, Warto odroczyć proces ustawiania adresów URL w witrynie względnych do czasu, aż wystarczająca liczba reklamodawców będzie prawidłowo współdziałać.