Przekierowanie HTTP → HTTPS

Przekierowanie HTTP → HTTPS to parametr monitoringu stron internetowych, który sprawdza, czy żądanie wysłane na adres http:// domeny kończy się pod adresem https://. Pomiar podąża za kolejnymi przekierowaniami i ocenia adres końcowy. Możliwe wyniki to: przekierowanie na HTTPS, brak przekierowania (strona odpowiada przez nieszyfrowane HTTP), błąd połączenia albo brak odpowiedzi w wyznaczonym czasie. Rozróżnienie ma znaczenie, bo według RFC 9110 zasoby udostępniane w schemacie https nie mają wspólnej tożsamości ze schematem http i są osobnymi źródłami (ang. origins) ^[1].

Jak działa

Odpowiedź z klasy 3xx oznacza, że klient musi wykonać dodatkowe działanie, aby zrealizować żądanie ^[1]. Kody 301, 302, 307 i 308 wskazują, że zasób może być dostępny pod innym adresem, podanym w nagłówku Location ^[1]. Gdy odpowiedź zawiera ten nagłówek, przeglądarka może automatycznie powtórzyć żądanie pod nowym adresem, nawet jeśli nie rozpoznaje konkretnego kodu ^[1].

Kody różnią się trwałością i traktowaniem metody. Kody 301 i 308 oznaczają, że zasób dostał nowy stały adres i przyszłe odwołania powinny używać nowego ^[1]. Kody 302 i 307 oznaczają przeniesienie tymczasowe, po którym klient powinien dalej używać adresu pierwotnego ^[1]. Z przyczyn historycznych przeglądarka może po odpowiedzi 301 lub 302 zamienić metodę POST na GET; kody 307 i 308 dodano właśnie po to, by jednoznacznie zachować metodę ^[1]. Przy zwykłym otwarciu strony, czyli żądaniu GET, 301 i 308 dają ten sam efekt. Różnica wychodzi przy formularzach i interfejsach API, które wysyłają POST na adres http://.

RYS. 1.1Przekierowanie na HTTPS

Serwer, który otrzymuje żądanie przez niezabezpieczony kanał, powinien według RFC 6797 odpowiedzieć przekierowaniem stałym, np. 301, z adresem https w nagłówku Location ^[2]. Nagłówka Strict-Transport-Security nie wolno wysyłać w odpowiedzi przez HTTP ^[2], więc przeglądarka dostaje go dopiero z odpowiedzią po HTTPS i od tej pory sama zamienia adresy http na https, bez przekierowania ^[3]. Mechanizm opisuje osobny artykuł HSTS.

Poprawny łańcuch kończy się na jednej formie adresu. Google zaleca wybrać jeden z adresów, pod którymi strona jest dostępna, i przekierować ruch z pozostałych na adres preferowany ^[5].

RYS. 1.2Poprawny łańcuch przekierowań

Standardy i specyfikacje

• RFC 9110 definiuje klasę 3xx, nagłówek Location oraz znaczenie kodów 301, 302, 307 i 308 ^[1].
• RFC 6797 zaleca przekierowanie stałe z HTTP na HTTPS jako „SHOULD”, a nie „MUST”. Powodem są m.in. ryzyka przekierowań po stronie serwera i witryny z komponentami zewnętrznymi, które mogą przy nich działać niepoprawnie ^[2].
• Google Search Central: przy przekierowaniu stałym (301, 308) proces indeksowania używa go jako sygnału, że cel powinien być adresem kanonicznym, a przy tymczasowym (302, 307) nie ^[5]. Gdy adres strony w wynikach ma się zmienić, Google zaleca stałe przekierowanie po stronie serwera ^[5]. Przekierowanie jest silnym sygnałem kanoniczności ^[6], a Google preferuje stronę HTTPS przed jej odpowiednikiem HTTP ^[6].
• Lighthouse w audycie przekierowania zmienia adres strony na HTTP, wczytuje ją i czeka na zdarzenie oznaczające bezpieczną stronę. Brak zdarzenia w ciągu 10 sekund oznacza niezaliczony audyt ^[7]. Jako naprawę dokumentacja podaje przekierowanie na serwerze i link kanoniczny w nagłówku dokumentu HTML ^[7].

Zagrożenia i skutki

Pierwsze żądanie bez szyfrowania. Przekierowanie nie chroni samego pierwszego żądania. Gdy użytkownik wpisuje adres http:// albo otwiera taki link, a przeglądarka nie zna jeszcze polityki HSTS hosta, pierwsza wymiana idzie niezabezpieczonym kanałem i jest podatna na ataki ^[2]. MDN wskazuje tę samą słabość HSTS i podaje listę preload jako sposób jej ograniczenia ^[3]. Znanym przykładem jest atak SSL stripping, dla którego Moxie Marlinspike opublikował narzędzie typu man-in-the-middle o nazwie sslstrip ^[4].

Brak przekierowania. Strona dostępna jednocześnie pod http:// i https:// ma dwa osobne źródła ^[1], a wersja HTTP działa bez ochrony transportu. Dokumentacja Lighthouse przyjmuje, że każda witryna powinna być chroniona przez HTTPS ^[7].

Przekierowanie tymczasowe. Kody 302 i 307 nie wskazują adresu kanonicznego, więc w wynikach wyszukiwania może zostać adres źródłowy ^[5].

Łańcuch przez HTTP i sprzeczne sygnały. Google nie daje pierwszeństwa stronie HTTPS, gdy ma ona nieważny certyfikat, przekierowuje użytkownika do strony HTTP lub przez nią albo wskazuje wersję HTTP w rel="canonical" ^[6].

Szyfrowanie kończone na proxy. Gdy TLS kończy się na load balancerze lub reverse proxy, zmienna %{HTTPS} w Apache zawsze ma wartość off, nawet jeśli klient połączył się przez HTTPS ^[8]. Reguła oparta na tej zmiennej przekierowuje wtedy również żądania, które były już szyfrowane. Dokumentacja zaleca sprawdzanie nagłówka X-Forwarded-Proto, ale tylko wtedy, gdy administrator kontroluje proxy, bo nagłówek da się podrobić ^[8].

Przykłady

Środowisko	Konfiguracja	Uwagi
Apache, host wirtualny portu 80	Redirect permanent "/" "https://www.example.com/"	podejście zalecane, bez mod_rewrite [8]
Apache, plik .htaccess	RewriteCond "%{HTTPS}" !=on i RewriteRule "^(.*)" "https://%{SERVER_NAME}$1" [R=301,L]	gdy brak dostępu do głównej konfiguracji; R=301 to przekierowanie stałe [8]
Apache za proxy TLS	RewriteCond "%{HTTP:X-Forwarded-Proto}" =http [NC]	zamiast %{HTTPS}, które za proxy zawsze jest off [8]
Apache z klientem ACME	wyjątek dla /.well-known/acme-challenge/ przed regułą	walidacja domeny przez zwykłe HTTP [8]
nginx	osobny blok server z return 301 i zmienną $request_uri	dokumentacja nazywa to właściwym sposobem zamiast if z rewrite; jej przykład dotyczy nazwy hosta [9]
WordPress	stałe WP_HOME i WP_SITEURL z https:// w wp-config.php	nadpisują wartości home i siteurl z tabeli wp_options, nie zmieniając bazy [10]