Czy jest jakiś powód, by nie wymuszać HTTPS na stronie internetowej?

Często odwiedzana przeze mnie witryna postanowiła włączyć TLS na swoje serwery, ale nie nakazuje tego, jak robi to wiele stron internetowych. Opiekun twierdzi, że TLS musi być opcjonalny. Dlaczego?

Na własnej stronie internetowej od dawna konfiguruję obowiązkowe TLS i HSTS z długimi okresami, a słabsze zestawy szyfrów są wyłączone. Dostęp do zwykłego tekstu jest gwarantowany za pomocą HTTP 301 do wersji chronionej TLS. Czy wpływa to negatywnie na moją stronę internetową?

Istnieje kilka dobrych powodów, aby używać TLS

(i tylko kilka marginalnych powodów, aby tego nie robić).

• Jeśli witryna ma jakieś uwierzytelnianie, użycie HTTP naraża do kradzieży sesji i haseł.

• Nawet w statycznych, czysto informacyjnych witrynach, korzystanie z TLS zapewnia, że ​​nikt nie manipulował danymi.

• Od czasu Google I / O 2014 Google podjęło kilka kroków, aby zachęcić wszystkie witryny do korzystania z HTTPS:

  • Google pomagał webmasterom w bezpieczniejszym konfigurowaniu swoich serwerów, ale również używał HTTPS jako sygnału rankingowego .
  • Niedawno Google Chrome zaczął oznaczać witryny HTTP jako niezabezpieczone , w ramach długoterminowego planu oznaczania wszystkich witryn HTTP jako niezabezpieczone .
  • Wykład zespołu HTTPS Google Developers zespołu Mythbusting jasno określa ich podejście.

• Blog bezpieczeństwa Mozilli ogłosił również, że wycofuje niezabezpieczony HTTP , udostępniając wszystkie nowe funkcje tylko dla bezpiecznych stron internetowych i stopniowo wycofując dostęp do funkcji przeglądarki dla niezabezpieczonych stron internetowych, szczególnie tych, które stanowią zagrożenie dla bezpieczeństwa i prywatności użytkowników .

Istnieje również kilka dobrych powodów do egzekwowania TLS

Jeśli masz już powszechnie zaufany certyfikat, dlaczego nie zawsze go używać? Praktycznie wszystkie obecne przeglądarki obsługują TLS i mają zainstalowane certyfikaty root. Jedynym problemem, jaki faktycznie widziałem od lat, są urządzenia z Androidem i brak pośredniego urzędu certyfikacji, ponieważ Android bezpośrednio ufa głównym urzędom certyfikacji. Można temu łatwo zapobiec, konfigurując serwer tak, aby wysyłał łańcuch certyfikatów z powrotem do głównego urzędu certyfikacji.

Jeśli Twój opiekun nadal chce zezwalać na połączenia HTTP bez bezpośredniego połączenia 301 Moved Permanently, powiedzmy w celu zapewnienia dostępu z niektórych naprawdę starych przeglądarek lub urządzeń mobilnych, przeglądarka nie może wiedzieć, że masz skonfigurowaną HTTPS . Ponadto nie należy wdrażać protokołu HTTP Strict Transport Security (HSTS) bez 301 Moved Permanently:

7.2.  HTTP Request Type

   If an HSTS Host receives a HTTP request message over a non-secure
   transport, it SHOULD send a HTTP response message containing a status
   code indicating a permanent redirect, such as status code 301
   (Section 10.3.2 of [RFC2616]), and a Location header field value
   containing either the HTTP request's original Effective Request URI
   (see Section 9 "Constructing an Effective Request URI") altered as
   necessary to have a URI scheme of "https", or a URI generated
   according to local policy with a URI scheme of "https").

Problem różnych witryn skonfigurowanych dla obu protokołów został rozpoznany przez The Tor Project i Electronic Frontier Foundation i rozwiązany przez rozszerzenie HTTPS Everywhere dla wielu przeglądarek :

Wiele witryn w sieci oferuje ograniczoną obsługę szyfrowania przez HTTPS, ale utrudnia korzystanie z nich. Na przykład mogą domyślnie używać niezaszyfrowanego HTTP lub wypełniać zaszyfrowane strony linkami, które prowadzą do niezaszyfrowanej witryny.

Mieszana zawartość była również ogromnym problemem ze względu na możliwe ataki XSS na strony HTTPS poprzez modyfikację JavaScript lub CSS ładowanego przez niezabezpieczone połączenie HTTP. Dlatego obecnie wszystkie przeglądarki głównego nurtu ostrzegają użytkowników o stronach o mieszanej zawartości i odmawiają automatycznego ładowania. To sprawia, że trudno utrzymać witryny bez 301przekierowań na http: należy upewnić się, że każda strona ładuje tylko contect HTTP HTTP (CSS, JS, obrazy etc.) i każdą stronę HTTPS HTTPS tylko ładuje zawartość. Jest to niezwykle trudne do osiągnięcia w przypadku obu tych samych treści.

W dzisiejszych czasach TLS + HSTS są znakami, że twoją witryną zarządzają profesjonaliści, którym można zaufać, aby wiedzieć, co robią. Jest to nowo powstały minimalny standard wiarygodności, o czym świadczy Google, który zapewni pozytywny ranking stron, które to robią.

Z drugiej strony jest maksymalna kompatybilność. Nadal są tam starsi klienci, szczególnie w częściach świata, które nie są Stanami Zjednoczonymi, Europą ani Chinami. Zwykły HTTP zawsze będzie działał (choć nie zawsze działa dobrze ; to inna historia).

TLS + HSTS: Optymalizacja pod kątem rankingu wyszukiwarek
Zwykły HTTP: Optymalizacja pod kątem zgodności

Zależy od tego, co jest dla Ciebie ważniejsze.

Jest jeden dobry powód, dla którego proste witryny tylko do odczytu nie używają HTTPS.

• Pamięci podręczne nie mogą buforować obrazów przesyłanych przez HTTPS.
• Niektóre części świata mają bardzo wolne połączenia międzynarodowe, więc zależą od pamięci podręcznych.
• Hostowanie obrazów z innej domeny wymaga umiejętności, których nie można oczekiwać od operatorów małych witryn tylko do odczytu .

Opiekun twierdzi, że TLS musi być opcjonalny. Dlaczego?

Aby naprawdę poznać odpowiedź na to pytanie, musisz je zadać. Możemy jednak zgadywać.

W środowiskach korporacyjnych IT często instaluje zaporę ogniową, która sprawdza ruch przychodzący i wychodzący pod kątem złośliwego oprogramowania, podejrzanych działań podobnych do CnC, treści uznanych za nieodpowiednie do pracy (np. Pornografii) itp. Staje się to znacznie trudniejsze, gdy ruch jest szyfrowany. Istnieją zasadniczo trzy możliwe odpowiedzi:

1. Zrezygnuj z monitorowania tego ruchu.
2. Zainstaluj główny urząd certyfikacji na komputerach użytkowników, aby móc przeprowadzać deszyfrowanie i inspekcję MitM.
3. Hurtowy blok szyfrowanego ruchu.

Dla zainteresowanego administratora żadna z tych opcji nie jest szczególnie atrakcyjna. Istnieje wiele zagrożeń atakujących sieć korporacyjną, a ich zadaniem jest ochrona firmy przed nimi. Jednak blokowanie bardzo wielu witryn całkowicie wzbudza gniew użytkowników, a instalowanie głównego urzędu certyfikacji może być nieco kłopotliwe, ponieważ wprowadza kwestie prywatności i bezpieczeństwa dla użytkowników. Pamiętam, jak widziałem (przepraszam, nie mogę znaleźć wątku) petycję sysadmin, reddit, kiedy po raz pierwszy włączali HSTS, ponieważ był w dokładnie takiej sytuacji i nie chciał blokować całej reddit po prostu dlatego, że był zmuszony przez biznes aby zablokować subreddity związane z pornografią.

Koła technologii wciąż się śmieją, a wielu z nich twierdzi, że tego rodzaju ochrona jest przestarzała i należy ją wycofać. Ale wciąż jest wielu, którzy to praktykują i być może to o nich troszczy się twój tajemniczy opiekun.

Wszystko sprowadza się do wymagań bezpieczeństwa, wyboru użytkownika i ryzyka niejawnego obniżenia oceny. Wyłączenie starych szyfrów po stronie serwera jest w dużej mierze konieczne, ponieważ przeglądarki z radością przechodzą do absolutnie okropnych szyfrów po stronie klienta w imię wygody / wygody użytkownika. Zapewnienie, że nic, co zależy od bezpiecznego kanału dla użytkownika, nie może być osiągnięte za pomocą niepewnej metody, jest oczywiście bardzo dobre.

Nie pozwalając mi wyraźnie obniżyć poziomu bezpieczeństwa do niezabezpieczonego HTTP, kiedy uznałem, że twój post na blogu o tym, dlaczego lubisz Python bardziej niż Ruby (nie mówiąc, że to robisz, to tylko ogólny przykład), nie jest czymś, co przeszkadza mi w oczach widowni lub opinii publicznej Udało mi się wejść bez przeszkód, przy założeniu, że HTTPS będzie dla mnie trywialny.

Istnieją obecnie systemy wbudowane, które nie mają możliwości korzystania z TLS po wyjęciu z pudełka, lub takie, które utknęły na starych implementacjach (myślę, że to okropnie źle, że tak jest, ale jako zaawansowany użytkownik [insert embedded urządzenie tutaj], czasem nie mogę tego zmienić).

Oto zabawny eksperyment: spróbuj pobrać najnowszą wersję LibreSSL z wcześniejszej strony OpenBSD przez HTTPS z wystarczająco starą implementacją TLS / SSL. Nie będziesz w stanie. Próbowałem pewnego dnia na urządzeniu ze starszą kompilacją OpenSSL od około 2012 roku, ponieważ chciałem uaktualnić ten system wbudowany do bezpieczniejszych, nowych rzeczy ze źródła - nie mam luksusu w postaci gotowego pakietu. Komunikaty o błędach, gdy próbowałem, nie były dokładnie intuicyjne, ale przypuszczam, że było tak, ponieważ mój starszy OpenSSL nie obsługiwał właściwych rzeczy.

Jest to jeden przykład, w którym przeniesienie HTTPS-a może w rzeczywistości zaszkodzić ludziom: jeśli nie masz luksusu z gotowych pakietów i chcesz samodzielnie rozwiązać problem, budując ze źródła, jesteś zablokowany. Na szczęście w przypadku LibreSSL możesz wrócić do jawnego żądania HTTP. Jasne, nie uratuje cię to od atakującego, który przepisuje ruch, który jest w stanie zastąpić pakiety źródłowe skompromitowanymi wersjami i przepisać wszystkie sumy kontrolne w treści HTTP opisujące pakiety dostępne do pobrania na przeglądanych stronach, ale nadal jest użyteczny częstszy przypadek.

Większość z nas nie jest ani jednym niezabezpieczonym plikiem pobranym od APT (Advanced Persistent Thread: żargon bezpieczeństwa dla krajowych agencji wywiadowczych i innych niezwykle dobrze wyposażonych cyberataków). Czasami potrzebuję po wgetprostu dokumentacji tekstowej lub małego programu, którego źródło mogę szybko skontrolować (na przykład moje małe narzędzia / skrypty w GitHub) na polu, które nie obsługuje najnowszych pakietów szyfrów.

Osobiście zadałbym to pytanie: czy twoje treści są takie, że osoba może zgodnie z prawem podjąć decyzję „Nie mam nic przeciwko dostępowi do wiedzy publicznej”? Czy istnieje realna szansa na realne ryzyko dla osób nietechnicznych przypadkowo obniżających standard HTTP do treści? Uwzględnij swoje wymagania bezpieczeństwa, wymuszone wymagania dotyczące prywatności użytkowników oraz ryzyko niejawnych obniżek w stosunku do zdolności użytkowników, którzy rozumieją ryzyko dokonywania świadomego wyboru w poszczególnych przypadkach, aby przejść bez zabezpieczenia. Całkowicie uzasadnione jest stwierdzenie, że w przypadku Twojej witryny nie ma dobrego powodu, aby nie egzekwować protokołu HTTPS - ale sądzę, że uczciwie jest powiedzieć, że nadal istnieją dobre przypadki użycia zwykłego protokołu HTTP.

Jest tu wiele dyskusji na temat tego, dlaczego tls jest dobry - ale nigdy o to nie pytano, jak w oryginalnym poście.

Maxthon zadał 2 pytania:

1) dlaczego losowa, nienazwana witryna postanowiła utrzymać obecność zarówno http, jak i https

2) Czy ma negatywny wpływ na to, że Maxthon obsługuje tylko 301 odpowiedzi na żądania http

W odniesieniu do pierwszego pytania nie wiemy, dlaczego dostawcy zdecydowali się zachować zarówno witryny http, jak i https. Powodów może być wiele. Oprócz kwestii związanych z kompatybilnością, rozproszonym buforowaniem i pewnymi wskazówkami na temat dostępności geopolitycznej, rozważa się także integrację treści i unikanie brzydkich wiadomości przeglądarki o tym, że treść jest niepewna. Jak zauważył Alvaro, TLS to tylko wierzchołek góry lodowej pod względem bezpieczeństwa.

Na drugie pytanie można jednak odpowiedzieć. Ujawnienie dowolnej części witryny za pośrednictwem protokołu HTTP, gdy faktycznie wymaga ona protokołu https do bezpiecznego działania, umożliwia wykorzystanie wektora do ataków. Jednak rozsądne jest utrzymanie tego w celu ustalenia, gdzie ruch jest nieprawidłowo kierowany do portu 80 w Twojej witrynie i ustalenia przyczyny. Tzn. Jest zarówno negatywny wpływ, jak i szansa na pozytywny wpływ, wynik netto zależy od tego, czy wykonujesz swoją pracę jako administrator.

Sysadmin1138 mówi, że https wpływa na ranking SEO. Chociaż Google stwierdził, że ma wpływ na rankingi, jedyne wiarygodne badania , które widziałem, sugerują, że różnica jest niewielka. Nie pomagają temu ludzie, którzy powinni wiedzieć lepiej, twierdząc, że ponieważ witryny o najwyższym rankingu częściej mają obecność https, obecność https poprawia zatem ranking.

W przeszłości musiałem używać HTTP zamiast HTTPS, ponieważ chciałem <embed>stron z innych stron, które same były obsługiwane przez HTTP, i inaczej nie działałyby.

To nie jest dobry powód, ponieważ oznacza to, że masz złych / uszkodzonych / niepewnych klientów, ale jeśli istnieją zautomatyzowane procesy uzyskujące dostęp do zasobów za pośrednictwem istniejących http://adresów URL, możliwe, że niektóre z nich nawet nie obsługują https (np. Wget busybox , który nie działa nie mają wewnętrznej obsługi TLS i dodali ją dopiero niedawno poprzez proces potomny openssl) i zerwaliby się, gdyby otrzymali przekierowanie na adres URL https, którego nie mogą śledzić.

Kusiłbym się, aby poradzić sobie z tą możliwością, pisząc regułę przekierowania, aby wykluczyć przekierowanie nieznanych (lub znanych wcześniej) ciągów User-Agent i pozwolić im uzyskać dostęp do treści za pośrednictwem http, jeśli chcą, aby wszystkie przeglądarki mogły skorzystać wymuszone https / hsts.

Istnieje bardzo niewiele dobrych powodów, aby używać HTTP zamiast HTTPS na stronie internetowej. Jeśli Twoja witryna obsługuje wszelkiego rodzaju transakcje lub przechowuje dane wrażliwe lub osobowe, musisz bezwzględnie użyć HTTPS, jeśli chcesz, aby te dane były bezpieczne. Jedynym słusznym powodem, dla którego nie wymuszam HTTPS, jest to, że witryna opiera się na buforowaniu, ponieważ HTTPS nie działa z buforowaniem. Jednak często warto poświęcić trochę wydajności, aby zapewnić bezpieczeństwo swojej witryny. Możliwe jest również, że Twoi klienci mogą nie obsługiwać HTTPS, ale tak naprawdę w 2017 r. Powinni.