Jaka jest korzyść z zmuszania witryny do ładowania przez SSL (HTTPS)?


55

Załóżmy, że mam dużą witrynę zawierającą tylko treści; bez logowania lub wylogowania, bez nazw użytkowników, bez adresów e-mail, bez bezpiecznego obszaru, bez tajemnic na stronie, nada. Ludzie po prostu przychodzą do witryny i przechodzą od strony do strony i sprawdzają zawartość.

Poza niewielkim wzrostem SEO w Google ( bardzo niewielkim, z tego, co przeczytałem), czy jest jakaś korzyść z zmuszania strony do ładowania za pośrednictwem HTTPS?


1
Nie wierzę, że jest to duplikat użycia siły przy użyciu protokołu SSL w witrynie? . Chociaż niektóre odpowiedzi mogą być podobne, w pytaniu tym pyta się o to, czy używać SSL, gdy nie jest to pytanie. Jeśli już, to drugie pytanie powinno zostać zamknięte, ponieważ jest oparte na opinii.
Stephen Ostermiller

4
Odwróćmy to: jaka jest korzyść z NIEużywania SSL? Nie znam nic takiego. No jasne, wdrożenie, które byłoby jednorazowe i nie zajęłoby (w porównaniu do wszystkiego innego) czasu. Tak więc, jeśli jedno podejście nie ma żadnych wad, a niektóre wady, drugie nie ma żadnych wad i (według ciebie) nie ma wad, to ... po co trzymać się tego drugiego?
VLAZ,

3
@Vld - wydajność. W dzisiejszych czasach często staramy się zoptymalizować czas ładowania strony początkowej do wyników poniżej sekundy, aby osiągnąć cel 1/2 sekundy. W przypadku nieco wolnego połączenia internetowego (opóźnienie pakietu około 100 ms) uzgadnianie protokołu SSL może z łatwością zająć 300 ms, co może zepchnąć Cię na wyższy poziom wydajności. Dla użytkowników mobilnych jest jeszcze gorzej: sieci komórkowe mają dłuższe opóźnienia pakietów, a czas przetwarzania weryfikacji certyfikatu może z łatwością wynosić kolejne kilkaset ms na wolniejszym telefonie.
Jules

6
Operatorzy komórkowi zawsze majstrują przy niezaszyfrowanym ruchu HTTP, niezależnie od tego, czy chodzi o kompresję obrazu (nad), wstrzykiwanie złego Javascript lub bardziej agresywne nagłówki kontrolujące pamięć podręczną. HTTPS zapobiegnie tym nonsensom.
André Borie

2
@Josef Nieprawda. HTTP / 2 działa równie dobrze na nieszyfrowanych połączeniach. Żadna przeglądarka nie może tego zrobić, ale to ograniczenie przeglądarki, nie HTTP / 2. Powiedzenie, że „HTTP / 2 działa tylko przez TLS” jest jak powiedzenie, że „technologia X nie działa, ponieważ Internet Explorer tego nie implementuje”. Zobacz, dokąd nas to zaprowadziło.
Agent_L,

Odpowiedzi:


84

HTTPS zapewnia nie tylko poufność (której wątpisz w wartość, choć istnieją ku temu dobre powody), ale także autentyczność , która zawsze ma wartość. Bez niego złośliwy punkt dostępowy / router / ISP / itp. może przepisać dowolną część witryny przed wyświetleniem jej użytkownikowi. Może to obejmować:

  • wstrzykiwanie reklam swoim konkurentom
  • wstrzykiwanie reklam lub irytujących widżetów, które sprawiają, że Twoja witryna wygląda źle i szkodzi Twojej reputacji
  • wstrzykiwanie exploitów w celu przeprowadzenia pobierania złośliwego oprogramowania na komputer odwiedzającego, który następnie (słusznie!) obwinia cię za to, co się dzieje
  • zastępując pliki do pobrania z Twojej witryny plikami zawierającymi złośliwe oprogramowanie
  • obniżenie jakości twoich zdjęć
  • usuwając części witryny, których nie chcą, abyś widział, np. rzeczy, które konkurują z własnymi usługami lub przedstawiają je w złym świetle
  • itp.

Brak ochrony użytkowników przed tymi rzeczami jest nieodpowiedzialny.


27
@Mike Nie bardzo. Jest do tego mnóstwo gotowego oprogramowania i wszystko to dobrze radzi sobie z dekompresją i rekompresją.
ceejayoz

3
@Mike Nie bardzo. Pełne proxy przepisujące może dekodować cały ruch i wstrzykiwać nowe rzeczy, których chce od nowa.
Nayuki,

10
Do Twojej wiadomości większość, jeśli nie wszystkie z moich przykładów, były widziane na wolności.
R ..

2
@DavidMulder twój pierwszy komentarz powiedział: „ de centralizacja [...] nie jest dobrą rzeczą”
jiggunjer

3
Czy nie możemy zamienić komentarzy na temat tej odpowiedzi w nie na temat motocykli, które dotyczą niezwiązanych ze sobą problemów?
R ..

25

„nic tajnego na stronie”

... Według ciebie . Może być doskonały powód, dla którego ktoś chce bezpiecznego połączenia. (Częściowo) tworzy prywatność:

Mój administrator widzi, że przeglądam stronę z obrazkami w telefonie za pośrednictwem adresu URL, ale nie może stwierdzić, czy oglądam zdjęcia uroczych kotów czy ostre filmy porno. Powiedziałbym, że to cholernie dobra prywatność. „treść” i „treść” mogą mieć znaczenie na całym świecie. - Agent_L

Możesz myśleć, że to nieistotne, a może nie jest to teraz wielka sprawa, ale może być w innym momencie. Jestem głęboko przekonany, że nikt oprócz mnie i strony internetowej nie powinien dokładnie wiedzieć, co robię.

Buduje zaufanie. Posiadanie kłódki jest oznaką bezpieczeństwa i może oznaczać pewne umiejętności w zakresie strony internetowej, a tym samym twoich produktów.

To czyni cię mniejszym celem np. Ataków MitM. Zwiększone bezpieczeństwo.

Dzięki inicjatywom takim jak Let's Encrypt , które sprawiają, że jest to dużo łatwiejsze i darmowe , nie ma wielu wad. Moc procesora pobierana przez SSL jest obecnie znikoma.


11
Niestety protokół SSL nie powstrzymuje informatyki korporacyjnej, dostawcy usług internetowych ani osób korzystających z Wi-Fi w publicznej kawiarni, aby nie wiedzieli, które strony odwiedzasz. Wyszukiwanie DNS jest nadal wykonywane w sposób wyraźny . Chociaż nie można zobaczyć treść, ani dokładnego adresu URL, ani nawet, że jesteś za pomocą przeglądarki internetowej, ale można zobaczyć, że masz dostęp penisland.com (co jest oczywiście miejsce dla miłośników pióra, ale może być źle zinterpretowany). Korzystanie z proxy VPN lub SOCKS5 chroni twoje zapytania DNS.
Schwern

3
@Martijn: Dzięki wskazaniu nazwy serwera (które obsługują wszystkie nowoczesne przeglądarki) nazwa hosta witryny jest wysyłana w sposób jawny w ramach uzgadniania HTTPS. To nie tylko kwestia ataków sidechannel i nie można go złagodzić za pomocą np. DNSsec.
Kevin

3
@ Schwern Nigdy nie zrozumiałem argumentu, że HTTPS nie chroni nazwy hosta, ponieważ wyszukiwanie DNS i SNI oraz certyfikat serwera są jasne. Oczywiście to prawda, jak stwierdzono, ale zwykły tekst HTTP nie jest pod tym względem lepszy!
CVn

5
@ Schwern Mój administrator widzi, że przeglądam tumblr na moim telefonie, ale nie może powiedzieć, czy oglądam zdjęcia uroczych kotów czy ostre filmy porno. Powiedziałbym, że to cholernie dobra prywatność. „treść” i „treść” mogą mieć znaczenie na całym świecie.
Agent_L

2
@Agent_L Nie, nawet to nie jest dobra rada. Jeśli przejdziesz do https://penisland.tumblr.com/przeglądarki, wykonasz żądanie DNS, dla penisland.tumblr.comktórego, chyba że zabezpieczyłeś swoje zapytania DNS, administrator sieci może to zobaczyć. Następnie Twoja przeglądarka musi pobrać obrazy, Javascript, CSS i reklamy z różnych domen, które generują więcej żądań DNS. Mogą pochodzić z dowolnej domeny. Kilka domen pornograficznych Tumblr, które próbowałem, nie ma nic oczywistego, Tumblr ma tendencję do przechowywania zdjęć i filmów w domu, ale nie możesz polegać na tym w kwestii prywatności.
Schwern

12

Otrzymujesz obsługę HTTP / 2 , nowego standardu internetowego zaprojektowanego w celu znacznej poprawy szybkości ładowania strony .

Ponieważ twórcy przeglądarek wybrali obsługę HTTP / 2 tylko przez HTTPS, włączenie HTTPS (na serwerze obsługującym HTTP / 2) jest jedynym sposobem na uzyskanie tego szybkiego uaktualnienia.


1
Jest to dość ogromne i należy go jeszcze bardziej zranić. Stanowi to uzasadnienie biznesowe dla ładowania HTTPS tylko tak, że większość menedżerów może się z tym opóźnić.
Dewi Morgan

10

(Części zaczerpnięte z mojej odpowiedzi na podobne pytanie).


HTTPS może osiągnąć dwie rzeczy:

  • Uwierzytelnianie . Upewnij się, że użytkownik komunikuje się z prawdziwym właścicielem domeny.
  • Szyfrowanie . Upewniając się, że tylko ten właściciel domeny i użytkownik mogą czytać ich komunikaty.

Prawdopodobnie wszyscy zgadzają się, że HTTPS powinien być obowiązkowy przy przesyłaniu tajemnic (takich jak hasła, dane bankowe itp.), Ale nawet jeśli twoja strona nie przetwarza takich tajemnic, istnieje kilka innych przypadków, w których i dlaczego użycie HTTPS może być korzystne.

Atakujący nie mogą manipulować przy żądanej treści.

Podczas korzystania z protokołu HTTP osoby podsłuchujące mogą manipulować treściami, które użytkownicy widzą w Twojej witrynie. Na przykład:

  • Dołączanie złośliwego oprogramowania do oprogramowania, które oferujesz do pobrania (lub jeśli nie oferujesz żadnego pobierania oprogramowania, atakujący zaczynają to robić).
  • Cenzurowanie niektórych treści. Zmieniam sposób wyrażania opinii.
  • Wstrzykiwanie reklam.
  • Zamiana danych konta darowizn na własne.

HTTPS może temu zapobiec.

Atakujący nie mogą odczytać żądanej treści.

Podczas korzystania z protokołu HTTP podsłuchujący mogą dowiedzieć się, do których stron / treści w hoście mają dostęp odwiedzający. Chociaż sama treść może być publiczna, wiedza, którą zużywa konkretna osoba, może być problematyczna:

  • Otwiera wektor ataku dla inżynierii społecznej .
  • Narusza to prywatność.
  • Może to prowadzić do inwigilacji i karania (aż do uwięzienia, tortur, śmierci).

Zależy to oczywiście od charakteru twoich treści, ale to, co wydaje ci się nieszkodliwe, może być różnie interpretowane przez inne strony.

Lepiej bądź bezpieczny niż przykro. HTTPS może temu zapobiec.


1
Rzeczywiście, HTTPS może temu zapobiec. W niektórych sytuacjach może nie być. Zobacz Lenovo Superfish na całkiem nowy przykład.
CVn

@ MichaelKjörling: Tak, jestem tego świadomy (dlatego upewniłem się, że użyłem „can”;)), ale jest to problem wynikający z zachowania odwiedzającego, a nie z samego HTTPS lub sposobu, w jaki webmaster używa prawda? Odwiedzający powinien dbać o to, którym urzędom certyfikacji należy ufać (a odwiedzający powinien dbać o to, które oprogramowanie zainstalować, szczególnie jeśli ma pozwolenie na manipulowanie listą urzędów certyfikacji, którym można ufać).
Unor

W rzeczy samej; Nie sprzeciwiam się twojemu punktowi, tylko go uzupełniam!
CVn

6

Zapobiega atakom typu man in the middle, które sprawiają, że myślisz, że odwiedzasz witrynę, ale przedstawia stronę, która faktycznie pochodzi z innej strony i może próbować uzyskać od ciebie informacje. Ponieważ dane są szyfrowane, intruzowi utrudnia również manipulowanie stroną w trakcie jej wyświetlania.

Ponieważ potrzebujesz certyfikatu SSL, który potwierdzi, że jesteś właścicielem strony, przynajmniej potwierdzając, kim jesteś.


3

Firmy marketingowe, takie jak Hitwise, płacą dostawcom usług internetowych za zbieranie danych o Twojej witrynie, gdy nie korzystasz z SSL. Gromadzone są dane o Twojej witrynie, o których konkurenci mogą nie wiedzieć:

  • dane demograficzne użytkowników
  • statystyki odwiedzin
  • popularne strony
  • słowa kluczowe w wyszukiwarkach (chociaż przy „nie podano” jest to obecnie mniejszy problem)

3

I, aby dodać jeszcze jedną rzecz do wszystkich odpowiedzi, powiem tylko o opóźnieniu. Ponieważ wydaje się, że nikt tu o tym nie napisał.

Niskie opóźnienie HTTP między klientem a serwerem ma kluczowe znaczenie dla tworzenia szybko ładujących się, responsywnych stron internetowych.

Sam TCP / IP ma 3-kierunkowy uścisk dłoni (wstępna konfiguracja połączenia dla zwykłego HTTP przez TCP wymaga 3 pakietów). Gdy używany jest protokół SSL / TLS, konfiguracja połączenia jest bardziej zaangażowana, co oznacza, że ​​opóźnienie dla nowych połączeń HTTPS jest nieuchronnie wyższe niż zwykły tekst HTTP.

Problem z HTTP polega na tym, że nie jest bezpieczny. Więc jeśli masz wrażliwe dane, potrzebujesz jakiejś formy bezpieczeństwa. Kiedy wpiszesz coś w przeglądarce zaczynającej się od „https”, poprosisz swoją przeglądarkę o użycie warstwy szyfrowania do ochrony ruchu. Zapewnia to rozsądną ochronę przed podsłuchującymi, ale problem polega na tym, że będzie wolniejszy. Ponieważ chcemy zaszyfrować nasz ruch, konieczne będą pewne obliczenia, co wydłuży czas. Oznacza to, że jeśli nie zaprojektujesz poprawnie swojego systemu, witryna będzie dla użytkowników powolna.

Podsumowując:

Mam dużą witrynę z treścią; bez logowania lub wylogowania, bez nazw użytkowników, bez adresów e-mail, bez bezpiecznego obszaru, bez tajemnic na stronie, nada. Ludzie po prostu przychodzą do witryny i przechodzą od strony do strony i sprawdzają zawartość.

W takim przypadku w ogóle nie będę używać protokołu SSL. Chciałbym, aby moja strona po kliknięciu otworzyła się w ciągu jednej sekundy. To z doświadczenia użytkownika. Robisz, co chcesz, po prostu nie umieszczam certyfikatów na wszystkim, co robię. W tym konkretnym przypadku nie użyłbym go wcale.


IMO, to jest tak samo poprawna odpowiedź, jak ta, która zdobyła wszystkie głosy.
Michael Yaeger,

youtube.com/watch?v=e6DUrH56g14 wspomina o niektórych technikach zmniejszania wpływu na wydajność, nawet jeśli z jakiegoś powodu nie możesz (lub duża część Twoich klientów) korzystać z HTTP / 2.
CVn

1

Oprócz korzyści wspomnianych przez innych, istnieje jeden powód, dla którego przełączysz się na SSL, chyba że nie obchodzi cię odwiedzający, którzy korzystają z Chrome - nowe wersje Chrome (o ile pamiętam od końca roku) są wyświetla ostrzeżenie (które odwiezie użytkowników od Twojej witryny) domyślnie dla wszystkich witryn, które nie używają HTTPS.

//EDYTOWAĆ:

Oto linki do dwóch bardziej szczegółowych artykułów, choć nie mogę znaleźć tego, o którym czytałem, kiedy planują oficjalnie wprowadzić tę funkcję:

https://motherboard.vice.com/read/google-will-soon-shame-all-websites-that-are-unencrypted-chrome-https

http://www.pandasecurity.com/mediacenter/security/websites-that-arent-using-https/


Nie jest to doskonały cytat z twierdzenia zawartego w odpowiedzi, ale zawsze jest oznaczanie HTTP jako niezabezpieczonego .
CVn

1

Prosta odpowiedź jest taka, że nie ma dobrego powodu, aby tego nie robić . W przeszłości istniały argumenty o używaniu protokołu SSL tylko wtedy, gdy jest to absolutnie konieczne (np. Na stronach e-commerce zbierających szczegóły płatności).

Miały one głównie związek z procedurą instalacji certyfikatów SSL, kosztami, dodatkowym obciążeniem serwera WWW i ograniczeniami sieci - w czasach, gdy ludzie nie mieli dostępu szerokopasmowego itp. Żaden z tych powodów tak naprawdę nie ma zastosowania w 2016 r.

Jeśli chodzi o SEO, wiemy, że celem większości wyszukiwarek jest zapewnienie najlepszych wyników dla ich użytkowników, a można to zrobić, zapewniając im bezpieczne połączenie z witryną, którą przeglądają. Pod tym względem wyszukiwarki nie dbają o to, czy na stronie znajdują się „wrażliwe” dane (prezentowane lub gromadzone); to po prostu przypadek, gdy witryna jest obsługiwana przez HTTPS, wszelkie potencjalne ryzyko uwierzytelnienia i szyfrowania jest znacznie zminimalizowane, więc witryna byłaby uważana za „lepszą” niż odpowiednik witryny bez HTTPS.

Zasadniczo jest to tak proste i łatwe do wdrożenia, że ​​jest obecnie postrzegane jako najlepsza praktyka. Jako twórca stron internetowych, po prostu rozważam zainstalowanie certyfikatu SSL, a następnie wymuszenie wszystkich żądań przez HTTPS (bardzo łatwe przy użyciu .htaccess lub równoważnego), aby były standardową częścią każdej witryny lub aplikacji internetowej, którą buduję.


1

Oprócz innych odpowiedzi przeglądarki powinny (podobnie jak w RFC 2119) wysłać User-Agentnagłówek. Dostarcza wystarczających informacji o tym, jakiej platformy używa użytkownik, jeśli wysyła faktyczną User-Agent. Jeśli Ewa będzie mogła podsłuchać żądanie złożone przez Alicję, a Alice wyśle ​​rzeczywistą User-Agent, Ewa będzie wiedziała, jakiej platformy używa Alice bez nawiązania połączenia z serwerem Eve. Przy takiej wiedzy łatwiej będzie włamać się do komputera Alice.


To trochę tak, jakby powiedzieć, że jeśli Ewa widzi numer VIN samochodu Alice przez przednią szybę samochodu, ułatwia Eve włamanie się do samochodu Alice, ponieważ numer VIN pozwala jej dowiedzieć się, jaką markę i model samochodu ma Alice. Jasne, jest taka możliwość, ale istnieje mnóstwo sposobów na uzyskanie takich samych informacji bez niczego w MITM, w sposób, który ledwo zarejestrowałby się jako coś więcej niż szum tła w Internecie dla węzła liścia w sieci. Na przykład: Ewa (a może Mallory) może wysłać Alicji link do strony internetowej pod ich kontrolą. Ludzie lubią klikać linki.
CVn

1

Masz dwie opcje zabezpieczenia swojej głównej domeny (mysite.com) i jej subdomen (play.mysite.com i test.mysite.com). SSL dotyczy nie tylko e-commerce, witryn sprzedawców płatności, w których transakcje finansowe lub dane logowania są udostępniane w witrynie. Jest to równie ważne w przypadku witryny opartej na treści. Atakujący zawsze szukają zwykłej witryny HTTP lub luki w witrynie. SSL nie tylko zapewnia bezpieczeństwo, ale także uwierzytelnia twoją stronę. Główną zaletą posiadania protokołu SSL w witrynie opartej na treści jest to, że:

  • Możesz uniknąć ataku typu man-in-middle, który może zmienić treść witryny.

  • Poza tym twoja strona internetowa będzie autentyczna, która powiadomi odwiedzających, że ich informacje zostaną zabezpieczone, jeśli udostępnią ją stronie internetowej.

  • Uzyskują pewność autentyczności witryny.

  • Co więcej, Twoja witryna będzie wolna od zastrzyków złośliwych reklam, exploitów, niechcianych widżetów, wymiany oprogramowania i szkód na stronach internetowych, gdy tylko będziesz mieć SSL na swojej stronie.

  • Certyfikat SSL oferuje statyczną pieczęć witryny, którą można umieścić na dowolnej stronie internetowej w celu zapewnienia bezpieczeństwa, a klienci mogą kliknąć pieczęć, aby poznać szczegóły zainstalowanego certyfikatu SSL.


1

Inne odpowiedzi mówiły o zaletach HTTPS. Czy użytkownik byłby zmuszony do korzystania z HTTPS? Z dwóch powodów:

  • Jeśli dasz użytkownikom opcję nieużywania HTTPS, prawdopodobnie nie zrobią tego, zwłaszcza że większość przeglądarek domyślnie używa http: //, a nie https: // podczas wpisywania domeny w pasku adresu.
  • Wdrażając zarówno wersję bezpieczną, jak i wersję niezabezpieczoną, zwiększasz powierzchnię ataku połączenia. Dajesz atakującym szansę przeprowadzenia ataku na obniżenie poziomu, nawet jeśli uważasz, że korzystasz z bezpiecznej wersji.
  • Jeśli przekierujesz każdy http: // URL na równoważny https: // one, ułatwi to życie administratorowi serwera i wyszukiwarek. Nikt nie musi się martwić, czy http: // i https: // mają być równoważne, czy też mają wskazywać na zupełnie różne rzeczy, przekierowując się nawzajem, jest jasne dla wszystkich, jakie adresy URL mają być używane.
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.