Czy wszystkie witryny powinny domyślnie używać protokołu SSL?

W odpowiedzi na ODPOWIEDŹ Tomasza :

Dla każdej witryny certyfikat SSL ma bezpośredni koszt. Mamy środowisko dev, qa i prod, a więc trzy certyfikaty, które są potrzebne dla każdej witryny

Prawie prawda. Nie musisz mieć każdego dev i qa za SSL z ważnymi, aktualnymi certyfikatami. Może chcesz mieć miejsce postoju z ważnym certyfikatem. Ale poza front-endem Apache, Twój back-end nie powinien wiedzieć, że istnieje SSL zaangażowany. Kupując certyfikaty deweloperów, nie testujesz niczego wyjątkowego ani specjalnego.

Również koszt jest nominalny. Wydajesz więcej pieniędzy na rozmowę, niż faktycznie kosztują certyfikaty.

Dla większości stron zawartość nie jest Bezpieczna, a wymuszanie SSL sprawiłoby, że żądania stron będą dłuższe na serwerze z powodu szyfrowania i deszyfrowania

Trochę. Mierzyłeś? Może się okazać, że jest to trudne do zmierzenia, ponieważ zmienność prędkości internetu przewyższa koszt przetwarzania SSL.

Z tego, co rozumiem, większość przeglądarek nie buforuje stron, które są SSL i tym samym ponownie, żądania stron będą trwać dłużej

Jeszcze raz, zmierzyłeś to?

Starsze przeglądarki mają problemy z pobieraniem plików, gdy są SSL'ed

Naprawdę? Którą konkretną "starszą przeglądarkę" planujesz obsługiwać, która ma ten problem? Jeśli nie możesz znaleźć i myślisz, że ktoś, gdzieś może mieć ten problem, może być overengineering. Sprawdź dzienniki i zobacz, jakich przeglądarek używają twoi klienci , a następnie określ, czy masz problem.

Zgadzam się, że "SSL wszędzie" nie jest zbyt dobrym podejściem. Myślę, że potrzebujesz co najmniej jednego portu non-SSL-80 "strona powitalna". Ale nie jestem pewien, czy twój obecny zestaw problemów to solidne powody. Myślę, że potrzebujesz znacznie więcej pomiarów, aby stwierdzić, że SSL faktycznie wiąże się z realnymi kosztami lub prawdziwe hity.

[1]} od 2012 r. witryny powinny używać protokołu SSL tylko wtedy, gdy mają dane osobowe (PII) lub ważne informacje handlowe, lub jeśli mają pojęcie logowania.

Witryny, które publikują tylko informacje publiczne o niskiej wartości i niskim zaufaniu, są nieco wątpliwe, ale prawdopodobnie nadal mogą służyć wszystkim za pośrednictwem HTTPS. Atakujący mogą próbować wstawić złośliwe oprogramowanie lub adware lub przekierowania do treści HTTP.

Polityka korporacyjna " wszystko przez SSL, bez szczególne zwolnienie " jest uzasadnione.

Należy również przyjrzeć się wdrożeniu http Strict Transport Security , aby upewnić się, że nawet pierwsze żądanie użytkownika od wpisania example.com jest wysyłane przez HTTPS.

SSL jest bezpiecznie buforowalny dla każdego użytkownika, zarówno podczas sesji, jak i na czas nieokreślony. Pamięci podręczne serwera proxy klienta są obecnie rzadkie i optymalizacja dla tego przypadku nie jest ważna. Kiedy już istnieją, często źle się czują i warto omijać je za pomocą protokołu SSL.

Poprawnie zaimplementowany SSL lub SPDY może być szybki: obciążenie serwera nie jest wysokie i można go łatwo przenieść na oddzielną maszynę odwrotnego proxy. Istnieją CDN SSL.

Szyfrowanie danych w sieci jest użyteczną warstwą głębokiej obrony. Oczywiście samo w sobie nie wystarczy, aby usługa była bezpieczna, ale eliminuje pewne problemy i ma niski koszt.

Nawet dla danych readonly, jest wartość w klientach wiedząc, że otrzymują autentyczną witrynę: dla jeśli pobierają pliki binarne, nie chcesz wstawiać trojanów.

Bezpieczne odróżnianie stron, które muszą być przez SSL od tych, które nie wymagają wysiłku programisty, który mógłby być prawie na pewno lepiej używany.

Uczynienie standardów kaftanem bezpieczeństwa dla różnych systemów, szczególnie bez konsultacji, nigdy nie jest dobre. Ale mówienie, że wszystkie witryny powinny być NA SSL, chyba że istnieje szczególny powód, aby zrobić inaczej w jednym przypadku, ma dla mnie sens. Dobre przykłady wyjątki dla poszczególnych przypadków, gdzie nadal powinieneś oferować SSL, ale nie wymuszać przekierowania:

Strona obsługuje duże pliki do pobrania (dystrybucja muzyki/wideo/oprogramowania), więc umożliwienie większej ilości pamięci podręcznej i szybszego pobierania jest ważne (Pokaż dane) [35]} Klienci są archaicznymi klientami IE lub embedded, które po prostu nie mogą odpowiednio wykonać SSL (ponownie, pokaż, że to rzeczywiście problem)]}
• jest bardzo wiele zasobów na stronie i chcesz, aby roboty indeksowały ją HTTPS

Jeśli używasz protokołu SSL wszędzie, użyjesz kilku dodatkowych zasobów maszyny, W sposób, który można zoptymalizować, jeśli staną się ważne. Jeśli nie używasz protokołu SSL, albo wydajesz więcej zasobów programistycznych, aby rozważyć bezpieczeństwo dla każdego przypadku, albo prawdopodobnie będziesz bardziej podatny na kradzież konta.

Adam Langley z Google napisał w 2010:

Jeśli jest jeden punkt, który chcemy przekazać światu, to jest to, że SSL / TLS nie jest obliczeniowo już drogo. 10 lat temu to mogła być prawda, ale tak już nie jest. Ty też możesz sobie pozwolić na włączenie HTTPS dla swoich użytkowników.

W styczniu tego roku (2010) Gmail domyślnie przełącza się na używanie HTTPS dla wszystkiego. Wcześniej został wprowadzony jako opcja, ale teraz wszyscy nasi użytkownicy używają HTTPS do zabezpieczania poczty e-mail między przeglądarkami a Google przez cały czas. Aby to zrobić, musieliśmy wdrożyć żadnych dodatkowych maszyn i specjalnego sprzętu. Na naszej interfejsy produkcyjne, SSL / TLS stanowią mniej niż 1% obciążenia procesora, mniej niż 10KB pamięci na połączenie i mniej niż 2% obciążenia sieci. Wiele osób uważa, że SSL zajmuje dużo czasu procesora i mamy nadzieję, że powyższe liczby (publiczne po raz pierwszy) pomogą to rozwiać.

Więc widziałem kilkafantastycznych odpowiedzi na to pytanie, ale po kilku dniach zobaczyłem, że brakujekilku rzeczy . Dlatego jest kilka rzeczy, o których chcę wspomnieć:

Po co używać SSL Na wszystkim

• bezpieczeństwo - jeśli tylko kilka stron jest szyfrowanych SSL, łatwiej jest "wywęszyć", które strony zawierają poufne dane. Teraz SSL jest cholernie bezpieczny, więc nie ma się czym martwić, ale w przypadku, gdy Twój klucz prywatny zostaje naruszony, dobrą praktyką jest posiadanie dodatkowej warstwy zabezpieczeń, aby trudniej bandziorom dostać się do soczystych rzeczy.
• wiarygodność - są ludzie, którzy twierdzą, że gdy odwiedzasz stronę, która ma zweryfikowany certyfikat, łatwiej jest zaufać. Ponieważ zweryfikowany certyfikat kosztuje pieniądze, łatwiej jest zaufać witrynie wiedząc, że właściciel zainwestował w symbol zaufania.
• Hassle - Blanketing everything under SSL jest o wiele łatwiejsze. Wszystko, co musisz zrobić, to odciąć http: na początku każdego linku zasobów i jesteś dobry.
• Konfiguracja SEO - nie musisz się w ogóle martwić o konfigurację SEO. Słyszałem, że wyszukiwarki indeksują http:// i https:// jako oddzielne wpisy, więc dla spójności (zarówno w SEO, jak i zachowaniu strony), blanketing SSL nad wszystkim i samo ustawienie przekierowania 301 wydaje się miłym, łatwym rozwiązaniem.
• - będziesz mieć o wiele bardziej spójną stronę internetową, jeśli tylko https:// wszystko. Wiele frameworków łamie się, gdy próbujesz zrobić hybrydę SSL i non-SSL. Ponadto wtyczki i Kod zależny od adresu URL będą naprawdę podłe, jeśli spróbujesz odbijać się tam iz powrotem między http i https.
• to rozmyte bezpieczne uczucie - musisz przyznać, że ten mały zielony pasek w lewym górnym rogu z napisem "zweryfikowana domena" jest cholernie dobrym uczuciem.

Dlaczego nie SSL Wszystko

• Speed - SSL jest wolniejszy. Oczywiście niewiele, a przez większość czasu koszt jest znikomy. Nieuniknionym faktem jest jednak, że SSL zawsze będzie wolniejszy.
• Zgodność przeglądarki - jest to prawdopodobnie znikome , ale jeśli chcesz wspierać naprawdę stare przeglądarki, które nie buforują przez SSL, będziesz musiał trzymać się Portu 80.
• pluginy - kilka pluginów nie działa poprawnie przez SSL, więc będziesz musisz na to uważać. Jeśli kiedykolwiek chcesz dodać nową wtyczkę, musisz ponownie skonfigurować ustawienia SSL lub poszukać innej wtyczki.
• profesjonalizm - teraz chociaż niektórzy twierdzą, że zobaczenie zweryfikowanej domeny SSL wydaje się godne zaufania, inni postrzegają ją jako bardzo amatorskie i leniwe rozwiązanie. W rzeczywistości jest to naprawdę łatwe i tanie (kosztowało mnie około $10), aby uzyskać zweryfikowany certyfikat SSL, który trafia do 96% przeglądarek!
• - więc powiedziałem, że to łatwiej SSL wszystko, ale w tym samym czasie będziesz musiał upewnić się, że każdy zasób jest ładowany przez https:// (lub zrobić http:// -> // szybkie rozwiązanie). Może to być nieco żmudne, jeśli masz kilka linków lub nawet niekompatybilne, jeśli masz Treści przesłane przez użytkowników hostowane w witrynie, która nie obsługuje protokołu SSL. W takich przypadkach twoja przeglądarka będzie na Ciebie jęczeć. Jeśli kiedykolwiek zauważyłeś, że "ta strona ma niebezpieczną zawartość", będziesz wiedział, jak irytujące jest to i jak złe wygląda.

Krótko mówiąc, to naprawdę sytuacyjne, ale mam tendencję do unikania blanketingu SSL. Oczywiście, wymaga to nieco większej konfiguracji, ale w końcu otrzymujesz znacznie bardziej elastyczny system. Osobiście uważam, że cały "profesjonalizm" to bzdura (Twitter i Google SSL wszystko). Jeśli jednak masz treści hostowane zewnętrznie lub treści publikowane przez użytkowników, zazwyczaj jest to naprawdę zły pomysł, aby wszystko SSL. Możesz również rozpocząć SSL-ing wszystko i natknąć się na kilka kłopoty.

To pierwsza rzecz, aby zadać sobie pytanie, co kupuje ci SSL? Kupuje ci pewność, że nikt i żadna aplikacja nie może "powąchać" ruchu i zobaczyć, co dzieje się między serwerem internetowym a przeglądarką. Koszt to rzeczywisty koszt zakupu certyfikatu SSL, a ciągły koszt niewielkiego wzrostu prędkości pobierania. Wspominasz, że starsza przeglądarka ma problemy z pobieraniem plików przez komunikację SSL. Nie mogę z tym rozmawiać i nie martwiłbym się tym zbytnio. Od masz inne zmartwienie. Nowoczesne zapory monitorują ruch w poszukiwaniu różnych prób włamania. SSL zapobiega monitorowaniu tej komunikacji przez zaporę sieciową, więc deweloper aplikacji / administrator sieci musi być jeszcze bardziej zaangażowany w ochronę swojej aplikacji i witryn przed różnymi próbami hakowania. Krótko mówiąc, należy szyfrować tylko te, które naprawdę tego potrzebują.

W innej odpowiedzi na Thomas answer, zwłaszcza, że jest na szczycie.

Ponadto, w dalszej części podlinkowałem białą księgę z najlepszymi praktykami dla SSL .

SSL zapobiega buforowaniu, nie tylko z przeglądarek, ale także z serwerów proxy. Każda strona www element będzie musiał być wysyłany przez główny serwer, wielokrotnie. Zwiększa to sieć ładuj.

Tylko częściowo prawda. SSL zapobiega buforowaniu proxy, ale nie buforowanie przeglądarki-Zobacz też odpowiedzi na to pytanie . Moim zdaniem nie jest to duży problem.

SSL uniemożliwia korzystanie z tzw. "domen wirtualnych". [...]

Jest to częściowo prawda. Jednak domeny wirtualne będą działać dobrze, o ile masz tylko jeden certyfikat. Nawet jeśli nie, wskazanie nazwy serwera (SNI) powinno być realną alternatywą (lub powinno być, gdy Windows XP jest poza twarzą planety).

[wydajność] jednak inicjowanie połączenia SSL, znany jako "uścisk dłoni", jest nieco droższy, > i może oznaczać wąskie gardło wydajności przy dużych obciążeniach (gdy są setki połączeń na sekundę lub więcej). Na szczęście dana instancja przeglądarki ponownie wykorzysta tunele i sesje SSL, dlatego nie jest to problem, jeśli masz tylko kilkudziesięciu użytkowników.

Nawet uścisk dłoni nie powinien powodować żadnych problemów z wydajnością po stronie serwera, jeśli masz nowoczesny sprzęt. Głównym powodem uścisku dłoni jest "powolny" ze względu na fakt że pakiety sieciowe muszą być wysyłane tam iz powrotem kilka razy między serwerem a przeglądarką - moc obliczeniowa ma z tym niewiele wspólnego.

Mówiąc inaczej: skonfigurowanie połączenia SSL będzie o rząd wielkości tańsze niż renderowanie strony PHP pobierającej dane z bazy danych.

Ogólnie rzecz biorąc, umieszczenie SSL wszędzie wygląda jak sposób na uzyskanie" ciepłego, rozmytego uczucia " w zakresie bezpieczeństwa. > Nie jest dobrze. Zazwyczaj oznacza to, że koncentrując się na nieistotne,

WCALE NIE PRAWDA . Albo w ogóle nie potrzebujesz SSL w swojej witrynie, ponieważ jest to całkowicie publiczna treść. Lub potrzebujesz SSL z jakiegoś powodu (loginy użytkowników, obszary chronione). W takim przypadku najlepszą praktyką jest umieszczenie go wszędzie.

Posiadanie SSL tylko na częściach strony może otworzyć Cię na wszelkiego rodzaju niejasne zagrożenia. I chociaż można je znaleźć i złagodzić na inne sposoby, będzie to bardziej złożone, podatne na błędy i czasochłonne niż tylko posiadanie SSL włączone na wszystkich stronach.

Znalazłem tę białą księgę na SSL. Nie jestem związany z firmą, która go stworzyła, ale uważam, że jest to bardzo zwięzłe podsumowanie wszystkich rzeczy, o których musisz pamiętać podczas wdrażania konfiguracji SSL.

To bezpieczeństwo ma więcej niż jeden element. Ale już pierwsze nieporozumienie nie jest dobrym początkiem.

Myślę, że nie powinieneś SSL wszystkich swoich witryn i zdecydowanie nie musisz kupować certów dla swoich środowisk programistycznych. Jeśli chcesz / potrzebujesz certyfikatu SSL dla dev, można go łatwo wygenerować i w większości przypadków byłoby to wystarczające dla tego środowiska. Inną możliwością jest to, że możesz kupić certyfikat wildcard i ustawić serwery dev w jednej z subdomen, w ten sposób możesz mieć ten sam certyfikat dla obu środowisk, ale znowu: to strata pieniędzy, jeśli kupisz wildcard certyfikat (które są droższe) po prostu mieć pracę dev na nim, jak również. Ma to sens, jeśli masz wiele subdomen na prod, które muszą być SSLed.

Co do szybkości: tak to trochę problem, ale nie aż tak istotny. Odpowiedzi SSL nie są buforowane, więc korzystanie z nich zwiększy obciążenie serwerów, ale myślę, że jest to część, o której administrator powinien być świadomy.