Uniemożliwia dostawcom usług internetowych wstrzykiwanie własnych reklam zamiast Twoich. Jeśli zarabiasz na reklamach, https pomaga chronić strumień przychodów.

Masz kilka dobrych pytań i kilka błędnych przekonań. Spróbujmy je rozplątać.

Mam też pewne pojęcie o innych korzyściach (np. Korzyściach szybkości z HTTP / 2).

Kolejna ważna one: Optymalizacja wyszukiwarek, ponieważ otrzymujesz punkty Google za posiadanie TLS. (co dowodzi, że webmasterzy potrzebują zewnętrznych zachęt ...)

Przypuszczam, że chciałbym również wiedzieć, że klient, z którym przeprowadzam transakcje, jest certyfikowany i informacje, które mu przesyłam jest zaszyfrowany. ... Ale czy żaden klient [sic] nie może uzyskać dostępu do mojej witryny internetowej z samodzielnie podpisanymi certyfikatami?

Tak i nie, i tak, ... i nie. Rozwiążmy to.

Uwierzytelnianie klienta TLS (wymagające od klientów przedstawienia certyfikatów) to coś, co zwykle widzisz na serwerach VPN, punktach dostępu WPA2 WiFi w przedsiębiorstwie i firmowych intranetach. Są to wszystkie zamknięte systemy, w których sysadmin ma pełną kontrolę nad wydawaniem certyfikatów użytkownikom i używa tego do kontrolowania, którzy użytkownicy mają dostęp do jakich zasobów. Nie ma to sensu w publicznych ustawieniach strony internetowej i jest zdecydowanie niestandardową konfiguracją dla serwera internetowego HTTPS.

To powiedziawszy, zyskujesz to:

  Szyfrowana sesja TLS | Klient ładuje stronę logowania | Klient wysyła nazwę użytkownika / hasło | Klient „jest zalogowany”  

Dzięki temu zyskujesz dodatkową pewność, że użytkownik jest tym, za kogo się podaje, ponieważ nazwa użytkownika / hasło nie są już wysyłane w sposób jawny, dlatego nie jest już możliwe dla pośrednika do przechwycenia / modyfikacji / kradzieży.

Następnie wszystkie dane, które klient wysyła na serwer lub pobiera z serwera, są szyfrowane od końca do końca do klienta. Ogólnie masz rację: chroni to klienta bardziej niż serwer, ale powstrzymuje pośredników przed wstrzykiwaniem złośliwych rzeczy do plików, które przesyła użytkownik, wstrzykując złośliwe polecenia do wykonania tak, jakby pochodziły od tego użytkownika .

Ale czy żaden klient nie może postępować nieetycznie i uzyskać dostępu do mojej witryny internetowej z własnymi podpisami certyfikatów itp., twierdząc, że jest kimkolwiek chce?

Coś tak. W przypadku publicznej witryny internetowej każdy może otworzyć połączenie TLS. Jeśli chcesz, aby użytkownicy uwierzytelniali się, musisz mieć na wierzchu mechanizm logowania, TLS generalnie tego nie zapewnia (chyba że używasz wspomnianego wyżej mechanizmu certyfikacji klienta).

Ale ostatnio zastanawiałem się, czy witryna skorzysta w podobny sposób z tej transakcji.

Zasadniczo korzyści dla serwera są takie, że wszelkie dane wysyłane do użytkownika będą być oglądane tylko przez zamierzonego użytkownika. Jeśli na przykład wysyłasz im kopie ich sprawozdań finansowych, wtedy Twoi prawnicy będą bardzo szczęśliwi, gdy to usłyszą. Oznacza to również, że wszelkie dane otrzymane od użytkownika faktycznie pochodziły od tego użytkownika, a nie od atakującego podszywającego się pod niego.

Jeśli Twoi uprawnieni użytkownicy działają złośliwie, to w końcu to inny problem, zdecydowałeś dać im dostęp do systemu. To, co robi TLS (+ twoja własna struktura logowania), to zapewnienie, że tylko uprawnieni użytkownicy mają dostęp. To, co robią z tym dostępem, nie jest problemem TLS.

Jedną z największych korzyści dla operatora witryny jest zwiększone zaufanie użytkowników ; często mamy nadzieję, że sprawdzają obecność HTTPS na przykład przed wprowadzeniem danych karty kredytowej do witryny e-commerce, a „zielona kłódka” certyfikatu EV zapewnia dodatkową weryfikację, że witryna jest obsługiwana przez podmiot, za którego się podają .

Jak duży to ma wpływ, nie wiem. Projekt Stanford Web Credibility zawiera zbiór zaleceń, jak uczynić witrynę internetową wiarygodną, ​​a HTTPS nie pojawia się na liście. Jednak cytowane tam dokumenty mają obecnie 15-20 lat. Wiele się wtedy zmieniło w technologii, ale prawdziwe pytanie brzmi: jak bardzo zmienili się ludzie .

HTTPS chroni tylko transport przed podsłuchiwaniem lub modyfikowaniem, tj. przed atakującym między klientem a serwerem, ale nie przed atakującym na serwerze lub samym kliencie. Nie sprawia, że ​​sam serwer jest magicznie bezpieczniejszy, ani nie zwiększa zaufania klienta do serwera. Oznacza to, że serwer chroniony przez HTTPS może na przykład obsługiwać złośliwe oprogramowanie, a klient łączący się przez HTTPS może nadal wykorzystywać problemy bezpieczeństwa po stronie serwera, takie jak wstrzyknięcie SQL lub podobne.

Wiele przeglądarek (Firefox robi to bardzo wyraźnie) ostrzega użytkowników przed wprowadzaniem haseł w niezabezpieczonych witrynach internetowych. Właściciele witryn naturalnie nie chcą, aby ich użytkownicy widzieli te straszne ostrzeżenia (które w przypadku Firefoksa utrudniają również korzystanie z automatycznie wypełnianych danych logowania), a jedynym sposobem na pozbycie się ich jest zabezpieczenie ich witryn.

Jeśli więc witryna umożliwia użytkownikom logowanie, istnieje silny bodziec do dodawania zabezpieczeń. Jest to zachęta zewnętrzna wymuszona przez dostawców przeglądarek.

Standardowa konfiguracja SSL jako taka nie zapewnia serwerowi żadnych korzyści w zakresie bezpieczeństwa. Wiedzą, że przesyłają dwa i od punktu końcowego, który przesłał zaszyfrowane żądanie, nie został zmanipulowany podczas przesyłania, ale nie ma gwarancji, że punkt końcowy, który wysłał żądanie, nie służy jako MITM.

Istnieje możliwość skonfigurowania SSL w taki sposób, aby sprawdzać poprawność klientów. Większość serwerów internetowych (Apache, nginx, IIS itp.) Umożliwia skonfigurowanie uwierzytelniania opartego na certyfikatach klienta, co oznacza, że ​​każdy klient uzyskujący dostęp do witryny będzie miał własny, unikalny certyfikat, a serwer sieciowy nie będzie obsługiwał stron żadnemu klientowi, nie ma ważnego certyfikatu. Dystrybucja i obsługa certyfikatów klienta to duże obciążenie, więc tego typu konfiguracja jest zwykle wykonywana tylko w środowiskach z ograniczoną liczbą klientów, takich jak aplikacje intranetowe, interfejsy API z niewielką liczbą użytkowników itp.

Jak dotąd dobre odpowiedzi, chcę tylko dodać następujące:

Nie każdy TLS (starszy SLL) ma ten sam poziom bezpieczeństwa, więc dobrze jest to sprawdzić na https: //www.ssllabs. com / ssltest /.

A TLSv3 ma pewne luki, więc poproś o wyłączenie w konfiguracji serwera.

Nie zamierzam mówić, że TLS jest kuloodporny w porównaniu z MitM, ponieważ wiemy, że usuwanie SSL i obejście HSTS jest możliwe, ale jest to znacznie trudniejsze dla atakującego, ponieważ musi znajdować się w tej samej sieci co użytkownik.

Największą korzyścią poza bezpieczną komunikacją jest to, że lepszy ranking Google SEO, ponieważ witryny z TLS stają się łatwiejsze na szczycie, jak podano tutaj http://searchengineland.com/google-starts-giving-ranking-boost-secure-httpsssl-sites-199446.

Wtedy jako firma użytkownik końcowy, widząc blokadę w przeglądarce internetowej, ma trochę bezpieczniejsze poczucie, wiem, że to trochę głupie, ponieważ ustawiłem wiele statycznych witryn z TLS / HTTPS, w których żadne dane nie były przesyłane z serwera lub na serwer, ale ze względu na SEO i wrażenia użytkownika końcowego .

Aby odgrywać rolę adwokata diabła, włączenie TLS na serwerze internetowym, jeśli go nie potrzebujesz (tj. żadne poufne informacje nie są przekazywane między serwerem a klientem) może w rzeczywistości obniżyć bezpieczeństwo .

Z prostego powodu: dodaje znacznie więcej kodu, a więcej kodu oznacza więcej błędów i większą powierzchnię ataku. Możesz więc napotkać takie problemy, jak Heartbleed, zdalne wykonanie kodu i inne problemy, których inaczej byś nie miał.

Oczywiście problem jest dyskusyjny - na pewno jest o wiele więcej błędy w każdym kodzie uruchamiającym twoją dynamiczną sieć niż w bibliotece TLS twojego serwera WWW, więc jeśli nie używasz bardzo małego kontrolowanego serwera HTTP ze statyczną zawartością, obniżenie bezpieczeństwa jest prawdopodobnie nieistotne.

A HTTPS ( oprócz bycia dobrym SEO dla Google i znajomych) może chronić Cię przed niektórymi zła, takimi jak ataki MitM (z drugiej strony, z powodu błędów w modelu HTTPS CA, jest to głównie „dobre samopoczucie”, „bezpieczeństwo” jesteś zmuszony „ufać” dziesiątkom urzędów certyfikacji, którym absolutnie nie ma powodu, by ufać w jakikolwiek sposób)

Korzyści dla właściciela witryny? Ich użytkownicy są bezpieczniejsi. Poza tym właścicielom witryn nie ma żadnej realnej korzyści i dlatego wiele witryn nadal nie ma protokołu HTTPS / SSL (ponieważ skonfigurowanie protokołu HTTP / SSL faktycznie wymaga pracy, z której właściciel witryny nie widzi żadnych bezpośrednich korzyści).

Zapewnienie bezpieczeństwa użytkownikom powinno być najważniejszym priorytetem właścicieli witryn, ale niestety często tak nie jest.

SSL zapewnia, że ​​ludzie nie mogą (łatwo) udawać Ciebie. To jest plus. Ponadto, jeśli masz do czynienia z informacjami umożliwiającymi identyfikację osoby (PII), SSL zapewnia dodatkowe zabezpieczenia, które pomagają uniknąć zakłopotania kogoś, kto wykradł dane klienta. W wielu krajach jesteś prawnie zobowiązany do podjęcia kroków w celu ochrony danych osobowych swoich klientów, a SSL jest jednym ze sposobów, w jaki możesz to zrobić.

Jeśli chcesz, aby Twoja witryna znajdowała się za pośrednictwem Google, SSL ma tę dodatkową zaletę, że zapewnia wyższą pozycję w wynikach wyszukiwania, choć tylko nieznacznie.

Jak zauważyli inni, SSL (lub TLS) zwiększa zaufanie użytkowników .

Unbounce zacytował to w artykule na blogu:

Jak odkrył GlobalSign, dostawca certyfikatów zaufania internetowego, 84% ankietowani użytkownicy witryny stwierdzili, że zrezygnowaliby z zakupu , gdyby wiedzieli, że dane zostaną wysłane przez niezabezpieczone połączenie .

W rzeczywistości wpływa to teraz bardziej bezpośrednio na właścicieli firm: Google Chrome zaczął oznaczać witryny bez SSL jako „niezabezpieczone”.

SSL / TLS ogranicza odpowiedzialność wobec właściciela witryny . Ruchu nie można łatwo sfałszować ani przechwycić. Twoi bardziej skłonni do procesowania się klienci nie będą mieli powodów do pozywania Cię za zaniedbanie.

Zyskujesz poprawę SEO w głównych wyszukiwarkach , w tym Google. Zobacz https://moz.com/blog/seo-tips-https-ssl

To nie kosztuje dużo . Dzięki dostawcom takim jak letsencrypt i menedżer certyfikatów AWS, konfiguracja bezpłatnych certyfikatów SSL / TLS jest łatwiejsza niż kiedykolwiek.