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

49

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

Maxthon Chan
źródło
12
Mogą obawiać się, że HSTS wpędzi ich w kłopoty, jeśli WSZYSTKO pójdzie nie tak (tj. Ich bezpłatny urząd certyfikacji przestanie wydawać certyfikaty lub zostanie usunięty z magazynów zaufanych przeglądarek z powodu jakiegoś problemu). Dzięki obecnemu ekosystemowi TLS tworzysz zależności od zaufanych urzędów certyfikacji / dostawców przeglądarki. Obecnie trudno go uniknąć i jest tego warty, ale nadal możesz to postrzegać jako problem i niewymuszanie HTTPS jako rozwiązania pozwalającego pozostać niezależnym na wypadek, gdyby coś się wydarzyło.
allo
każdy chce wspomnieć o wymaganiu tls dla h2, które jest znacznie szybsze niż http1.1. dobre dla ciebie robiącego hsts, niedawno wysłałem moją stronę na listę wstępnego ładowania hsts, mam nadzieję, że mogę po prostu całkowicie wyłączyć port 80
Jacob Evans
4
@gerrit Ten argument nie stoi przed tanim i bezpłatnym urzędem certyfikacji, takim jak Let's Encrypt.
Maxthon Chan
1
Let's Encrypt nie działa z każdym hostem i nie jest tak proste jak użycie lepszego hosta. Używam App Engine, który nie jest (bezpośrednio) obsługiwany z przyczyn technicznych.
Carl Smith

Odpowiedzi:

8

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:

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

Esa Jokinen
źródło
If your maintainer still would like to allow HTTP connections without direct 301 Moved Permanently, say for ensuring access from some really old browsers or mobile devices, HSTS is the correct choise as it only enforces HTTPS when it is clear that the browser supports itale w tym przypadku klient (nawet zgodny z HTTPS) nigdy nie dowie się o wersji HTTPS, jeśli początkowo ładuje HTTP.
Cthulhu,
Ostatni akapit: nagłówek HSTS jest ignorowany podczas połączenia innego niż HTTPS.
Cthulhu,
1
HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport. If an HTTP response is received over insecure transport, the UA MUST ignore any present STS header field(s). tools.ietf.org/id/draft-ietf-websec-strict-transport-sec-14.txt
Cthulhu
Dzięki za wskazanie mojej fałszywej wskazówki, Cthulhu! Zainspirowany tym dokonałem znacznej poprawy mojej odpowiedzi. Zachęcamy również do krytycznego traktowania nowych treści. :)
Esa Jokinen
62

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.

sysadmin1138
źródło
16
Może to ja jestem wybredna, ale to pierwsze zdanie wydaje się trochę rozciągnięte: strona będąca https nie mówi nic o profesjonalizmie ani wiarygodności osób odpowiedzialnych. Witryna może być https i nadal być rozwijana / zarządzana przez osoby, które nie dezynfekują danych wejściowych, co czyni witrynę podatną na iniekcję SQL lub XSS; lub może być https i być nieprawidłowy, niedostępny lub nieużyteczny.
Alvaro Montoro,
34
Korzystanie z HTTPS nie jest gwarancją profesjonalizmu, ale jego brak zdecydowanie wskazuje na coś przeciwnego.
Esa Jokinen,
8
Korzystanie z TLS i HSTS to sygnały, będące częścią znacznie większej tablicy, że strona może być warta przeczytania. W przeciwieństwie do innych, jego banalnie łatwy do przetestowania na obecność , dlatego Google używa go jako serwera proxy dla reszty.
sysadmin1138
3
@Braiam Stack Exchange migruje tylko do https i wkrótce zacznie używać hsts. Http jest nadal dostępny, nie ze względu na kompatybilność, ale dlatego, że są powolne i ostrożne, a migracja jest technicznie trudna.
captncraig
4
@esajohnson - brak https nie pokazuje nieprofesjonalizmu. Pokazuje, że nie ma takiej „potrzeby”. Na przykład lustro CentOS.
warren
30

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 .
Ian Ringrose
źródło
1
Treści tylko do odczytu można wdrożyć w sieci CDN, jeśli kierujesz reklamy na te kraje. CDN odzwierciedla zawartość statyczną własnymi środkami i nadal obsługuje je za pośrednictwem HTTPS. CDN może być dość łatwy do znalezienia, a dla małych stron internetowych nie jest tak drogi w użyciu.
Maxthon Chan,
8
@ MaxthonChan, spróbuj wyjaśnić mojej matce, czym jest CDN ..... Może jednak założyć stronę internetową z czasem lokalnych nabożeństw.
Ian Ringrose
6
@MichaelHampton, jak pamięć podręczna może odczytywać obraz ze strumienia HTTPS bez kluczy opisu? Czy zaufałbyś dostawcy usług internetowych za pomocą swoich kluczy?
Ian Ringrose
8
Powinieneś wyjaśnić, o których skrzynkach mówisz.
Michael Hampton
2
@IanRingrose Jeśli twoja matka zakłada stronę internetową z lokalnymi informacjami na temat nabożeństw, mało prawdopodobne jest, aby zachowanie buforowania na międzynarodowych połączeniach miało zastosowanie, chyba że jest to bardzo popularny kościół.
Jason C
14

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.

Xiong Chiamiov
źródło
co powiesz na zakończenie ssl na serwerze frontend / load balancer / podobnym i rejestrowanie ruchu po tym?
eis
1
@eis Zakłada, że ​​firma kontroluje każdą witrynę, którą pracownicy mogą odwiedzać, co jest mało prawdopodobne. Post wydaje się nie dotyczyć TLS na stronie intranetowej.
Xiong Chiamiov
5

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.

mtraceur
źródło
1
„spróbuj pobrać najnowszą wersję LibreSSL z wcześniejszej strony OpenBSD przez HTTPS przy użyciu wystarczająco starej implementacji TLS / SSL” . Drugą stroną tego jest oczywiście: spróbuj pobrać najnowszą przeglądarkę z wystarczająco starą przeglądarką, na przykład taką, która tylko implementuje HTTP / 1.0 bez obsługi Host:nagłówka. Lub spróbuj surfować po nowoczesnych witrynach za pomocą przeglądarki internetowej obsługującej tylko Javascript 2001. W pewnym momencie my, społeczność, musimy przejść dalej, co niestety dla niektórych psuje. Powstaje zatem pytanie: czy wartość dodana jest warta przełamania?
CVn
@ MichaelKjörling Są to również problemy o różnym nasileniu. Dodam kompilację najnowszych wersji kompilatora do tej listy. Niektóre są bardziej obronne niż inne. Nie jestem pewien, czy jesteś twierdząc sprzeciw lub dlaczego, jeśli: w drugim zdaniu mojego postu, zgadzam się, że to jest uzasadnione, aby zapobiec stare szyfry na połączenia HTTPS, ponieważ chroni większość użytkowników przed atakami zmiany wersji oni” d w przeciwnym razie nie mają znaczącej widoczności ani obrony przed nimi. (Nie sądzę, większość nowoczesnych stron internetowych braku wdzięcznie degradacji jest zdalnie za uzasadnione, ale to trochę mija się z celem.)
mtraceur
@ MichaelKjörling Aby to wyjaśnić, chodziło o to, że jest to przykład, w którym zapewnienie zwykłego protokołu HTTP użytkownikowi miał wyraźną korzyść, co było głównym punktem odpowiedzi na pytanie. Nie było w żaden sposób rzucić negatywnego światła na projekty OpenBSD / LibreSSL, na co mam dość duży szacunek. Myślałem, że drugie zdanie pierwszego akapitu wykluczałoby taką negatywną interpretację. Jeśli uważasz, że było to niejasne lub mogłoby być lepiej sformułowane, zredaguj moją odpowiedź lub zasugeruj ulepszenia.
mtraceur
3

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.

symcbean
źródło
1

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.

Algy Taylor
źródło
Możesz użyć swojego serwera do odwrócenia proxy wersji SSL.
Maxthon Chan,
1

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.

R ..
źródło
1
Przypomnij mi, ile lat temu jakieś dobrze utrzymane narzędzie (np. Wget) nie obsługiwało HTTPS?
Oleg V. Volkov
@ OlegV.Volkov: Myślę, że przegapiłeś słowo busybox w mojej odpowiedzi.
R ..
Sprawdziłem to - cóż, teraz widzę. Naprawdę nie rozumiem, dlaczego nie mogę po prostu zbudować tego cholerstwa, a potem nie pakować narzędzi do budowania, ale cokolwiek. Myśląc wstecz, przypomniałem sobie także kilka innych przypadków, w których ludzie ograniczali się do rozebranych lub przestarzałych narzędzi i dobrze byłoby mieć zwykły HTTP. Czy mógłbyś naprawić ograniczenia, aby móc cofnąć głosowanie również po edycji?
Oleg V. Volkov
1

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.

Rozpoznać
źródło