en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

en English
X

Select Language

Powered by Google TranslateTranslate

We hope you will find the Google translation service helpful, but we don’t promise that Google’s translation will be accurate or complete. You should not rely on Google’s translation. English is the official language of our site.

SSL /TLS Najlepsze praktyki na rok 2023

W 2023 r. Zabezpieczanie Twojej witryny SSL /TLS certyfikat nie jest już opcjonalny, nawet dla firm, które nie mają bezpośredniego kontaktu z poufnymi informacjami o klientach w sieci. Wyszukiwarki, takie jak Google, wykorzystują bezpieczeństwo witryny jako sygnał rankingowy SEO, a popularne przeglądarki internetowe, takie jak Chrome, ostrzegają użytkowników przed witrynami, które nie używają protokołu HTTPS:

Przeglądarka działająca na niezabezpieczonej stronie

Jednak perspektywa skonfigurowania serwerów internetowych i aplikacji do korzystania z SSL /TLS prawidłowy protokół może wydawać się onieśmielający, ponieważ istnieje wiele tajemnych konfiguracji i wyborów projektowych. Ten przewodnik zawiera krótkie omówienie głównych punktów, o których należy pamiętać podczas konfigurowania SSL /TLS dla Twojej witryny, koncentrując się zarówno na bezpieczeństwie, jak i wydajności. Wciąż jest wiele do omówienia tylko z podstawami, więc podzieliliśmy to na serię kroków.

SSL.com zapewnia szeroką gamę SSL/TLS certyfikaty serwera. Zabezpiecz swoją witrynę już dziś za pomocą certyfikatu SSL z SSL.com i buduj zaufanie wśród odwiedzających!

PORÓWNAJ SSL /TLS CERTYFIKATY

Wybierz wiarygodny urząd certyfikacji (CA)

Twoje certyfikaty są tak godne zaufania, jak wydający je urząd certyfikacji. Wszystkie publicznie zaufane urzędy certyfikacji podlegają rygorystycznym audytom zewnętrznym, aby utrzymać swoją pozycję w głównych systemach operacyjnych i programach certyfikatów głównych przeglądarek, ale niektóre z nich radzą sobie lepiej niż inne. Poszukaj urzędu certyfikacji, który (np SSL.com):

  • Prowadzi większość swojej działalności w obszarze publicznego zaufania PKI. Firmy te mają najwięcej do stracenia, jeśli wyjdą na jaw złe praktyki bezpieczeństwa i wszystko, co można zyskać, nadążając za zmieniającymi się standardami branżowymi.
  • Reaguje wydajnie i skutecznie na wykrycia luk w zabezpieczeniach wpływających na bezpieczeństwo i prywatność użytkowników, na przykład w branży entropia numeru seryjnego numer z początku 2019 r. Przeszukiwanie forów branżowych takich jak polityka.zabezpieczeń.mozilla.dev. może dać ci dobry pomysł na to, jak dany urząd certyfikacji reaguje na przeciwności losu.
  • Oferuje przydatne produkty i usługi, takie jak certyfikaty Extended Validation (EV), masowe / automatyczne wystawianie certyfikatów w sposób intuicyjny API albo Protokół ACME, łatwe zarządzanie cyklem życia certyfikatów i usługi monitorowania oraz wsparcie do integracji z obszerną listą rozwiązań innych firm.
  • Ma reputację doskonałej obsługi klienta i wsparcia technicznego. Dbanie o bezpieczeństwo witryny firmy w 100% jest ważne, a gdy coś pójdzie nie tak, musisz mieć możliwość skontaktowania się z prawdziwym ekspertem przez telefon.

Autoryzacja urzędu certyfikacji (CAA)

Autoryzacja urzędu certyfikacji (CAA) to standard ochrony witryn internetowych poprzez wyznaczenie określonych urzędów certyfikacji, które mogą wydawać certyfikaty dla nazwy domeny. Po wybraniu urzędu certyfikacji należy rozważyć konfigurowanie rekordów CAA autoryzować to.

Generuj i zabezpieczaj swoje klucze prywatne

Połączenia SSL /TLS protokół używa a para kluczy do uwierzytelniania tożsamości i szyfrowania informacji przesyłanych przez Internet. Jeden z nich ( klucz publiczny) jest przeznaczony do szerokiej dystrybucji, a drugi ( prywatny klucz) należy przechowywać tak bezpiecznie, jak to możliwe. Te klucze są tworzone razem podczas generowania żądanie podpisania certyfikatu (CSR). Oto kilka wskazówek dotyczących kluczy prywatnych:

  • Użyj silnych kluczy prywatnych: Większe klucze są trudniejsze do złamania, ale wymagają większego nakładu pracy. Obecnie zalecany jest co najmniej 2048-bitowy klucz RSA lub 256-bitowy klucz ECDSA, a większość stron internetowych może osiągnąć dobre bezpieczeństwo przy jednoczesnej optymalizacji wydajności i wrażeń użytkownika z tymi wartościami.
    Uwaga: Omówienie tych dwóch algorytmów można znaleźć w artykule SSL.com, Porównanie ECDSA z RSA.
  • Chroń swoje klucze prywatne:
    • Generuj własne klucze prywatne w bezpiecznym i zaufanym środowisku (najlepiej na serwerze, na którym zostaną wdrożone lub na urządzeniu zgodnym ze standardem FIPS lub Common Criteria). Nigdy zezwól CA (lub komukolwiek innemu) na generowanie kluczy prywatnych w Twoim imieniu. Renomowany publiczny urząd certyfikacji, taki jak SSL.com, nigdy nie zaoferuje wygenerowania lub obsługi kluczy prywatnych, chyba że zostały one wygenerowane w bezpiecznym tokenie sprzętowym lub HSM i nie można ich eksportować.
    • Udzielaj dostępu do kluczy prywatnych tylko w razie potrzeby. Wygeneruj nowe klucze i unieważnić wszystkie certyfikaty dla starych kluczy, gdy pracownicy z dostępem do klucza prywatnego opuszczają firmę.
    • Odnawiaj certyfikaty tak często, jak jest to praktycznie możliwe (przynajmniej raz w roku), najlepiej za każdym razem używając świeżo wygenerowanego klucza prywatnego. Narzędzia do automatyzacji, takie jak Protokół ACME są pomocne przy planowaniu częstych odnowień certyfikatów.
    • Jeśli klucz prywatny został (lub mógł zostać) przejęty, unieważnić wszystkie certyfikaty dla tego klucza, wygeneruj nową parę kluczy i wystaw nowy certyfikat dla nowej pary kluczy.

Skonfiguruj swój serwer

Na powierzchni, instalacja SSL /TLS świadectwo może wydawać się prostą operacją; jednak nadal istnieje wiele decyzji konfiguracyjnych, które należy podjąć, aby zapewnić szybki i bezpieczny serwer WWW oraz zapewnić płynne działanie, wolne od błędów i ostrzeżeń przeglądarki. Oto kilka wskazówek dotyczących konfiguracji, które ułatwią Ci skonfigurowanie protokołu SSL /TLS na twoich serwerach:

  • Upewnij się, że wszystkie nazwy hostów są objęte gwarancją: Czy Twój certyfikat obejmuje nazwę domeny Twojej witryny zarówno z rozszerzeniem www prefiks? Czy istnieje Alternatywna nazwa podmiotu (SAN) dla każdej nazwy domeny, którą certyfikat ma chronić?
  • Zainstaluj kompletne łańcuchy certyfikatów: SSL jednostki końcowej /TLS certyfikaty są zwykle podpisywane przez certyfikaty pośrednie, a nie przez klucz główny urzędu certyfikacji. Upewnij się, że na serwerze sieciowym są zainstalowane wszelkie certyfikaty pośrednie, aby zapewnić przeglądarkom pełną wersję ścieżka certyfikacji i unikaj ostrzeżeń i błędów dla użytkowników końcowych. Twój CA będzie w stanie zapewnić wszelkie niezbędne półprodukty; Klienci SSL.com mogą korzystać z naszego Pobieranie certyfikatu pośredniego strona, aby pobrać pakiety pośrednie dla wielu platform serwerowych.
  • Użyj aktualnego SSL /TLS Protokoły (TLS 1.2 lub 1.3): Pod koniec 2018 r. Wszyscy główni dostawcy przeglądarek ogłosili plany wycofania TLS 1.0 i 1.1 do pierwszej połowy 2020 roku. Google przestarzałe TLS v1.0 i v1.1 w Chrome 72 (wydany 30 stycznia 2919). Chrome w wersji 84 (wydanej 14 lipca 2020 r.) i nowszych zawiera pełnoekranowe ostrzeżenie dotyczące tych protokołów, a pomoc techniczna miała zostać całkowicie usunięty w maju 2021 roku. Szeroka obsługa przeglądarek z wcześniejszym SSL /TLS wersje, takie jak SSL v3, już dawno minęły. Podczas TLS 1.2 jest obecnie najczęściej używaną wersją protokołu SSL /TLS protokół, TLS 1.3 (najnowsza wersja) to już obsługiwane w aktualnych wersjach większości głównych przeglądarek internetowych.
  • Użyj krótkiej listy bezpiecznych pakietów szyfrów: Wybierz tylko pakiety szyfrów, które oferują szyfrowanie co najmniej 128-bitowe lub silniejsze, jeśli to możliwe. Narodowy Instytut Standardów i Technologii (NIST) również to zaleca TLS implementacje odchodzą od zestawów szyfrów zawierających szyfr DES (lub jego warianty) na rzecz tych używających AES. Wreszcie, użycie tylko niewielkiego podzbioru potencjalnie akceptowalnych zestawów szyfrów minimalizuje powierzchnię ataku dla jeszcze nieodkrytych luk w zabezpieczeniach. Dodatek do SSL.com Przewodnik po TLS Zgodność z normami zapewnia przykładowe konfiguracje dla najpopularniejszych platform serwerów WWW, używając TLS 1.2.
    Uwaga: Używanie niepewnych, przestarzałych szyfrów (takich jak RC4) może powodować błędy bezpieczeństwa przeglądarki, takie jak ERR_SSL_VERSION_OR_CIPHER_MISMATCH w Google Chrome.
  • Użyj Forward Secrecy (FS): znany także jako idealna tajemnica do przodu (PFS), FS zapewnia, że ​​skompromitowany klucz prywatny nie wpłynie również na klucze poprzednich sesji. Aby włączyć FS:
    • Konfigurowanie TLS 1.2, aby użyć algorytmu wymiany klucza Elliptic Curve Diffie-Hellman (EDCHE) (z DHE jako rezerwą) i jeśli to możliwe, unikaj wymiany kluczy RSA całkowicie.
    • Zastosowanie TLS 1.3. TLS 1.3 zapewnia wszystkim tajemnicę do przodu TLS sesje za pośrednictwem Efemeryczny Diffie-Hellman (EDH lub DHE) protokół wymiany kluczy.
  • umożliwiać TLS Wznowienie sesji: Podobnie jak używanie keepalives do utrzymywania trwałych połączeń TCP, TLS wznowienie sesji umożliwia serwerowi WWW śledzenie ostatnio wynegocjowanego SSL /TLS sesje i wznów je, omijając narzut obliczeniowy związany z negocjowaniem klucza sesji.
  • Rozważ zszywanie OCSP: Zszywanie OCSP umożliwia serwerom internetowym dostarczanie przechowywanych w pamięci podręcznej informacji o odwołaniu bezpośrednio do klienta, co oznacza, że ​​przeglądarka nie będzie musiała kontaktować się z serwerem OCSP w celu sprawdzenia, czy certyfikat witryny został odwołany. Eliminując to żądanie, zszywanie OCSP zapewnia prawdziwy wzrost wydajności. Aby uzyskać więcej informacji, przeczytaj nasz artykuł, Optymalizacja ładowania strony: Zszywanie OCSP.

Użyj najlepszych praktyk w zakresie projektowania aplikacji internetowych

Projektowanie aplikacji internetowych z myślą o bezpieczeństwie jest tak samo ważne, jak prawidłowe skonfigurowanie serwera. Są to najważniejsze punkty zapewniające, że Twoi użytkownicy nie są narażeni na działanie Mężczyzna w środku ataki i że Twoja aplikacja uzyskuje korzyści SEO wynikające z dobrych praktyk bezpieczeństwa:

  • Wyeliminuj mieszane treści: Pliki JavaScript, obrazy i pliki CSS powinny cała kolekcja mieć dostęp za pomocą SSL /TLS. Jak opisano w artykule SSL.com, HTTPS Everywhere, służąc mieszana zawartość nie jest już akceptowalnym sposobem na zwiększenie wydajności witryny i może powodować ostrzeżenia bezpieczeństwa przeglądarki i problemy z SEO.
  • Użyj bezpiecznych plików cookie: Ustawianie Secure flaga w plikach cookie wymusi transmisję za pośrednictwem bezpiecznych kanałów (np. HTTPS). Możesz także uniemożliwić JavaScript dostępu do plików cookie po stronie klienta za pośrednictwem HttpOnly oflaguj i ogranicz użycie plików cookie między witrynami za pomocą SameSite flag.
  • Oceń kod innej firmy: Upewnij się, że rozumiesz potencjalne zagrożenia związane z używaniem bibliotek innych firm w swojej witrynie, takie jak możliwość nieumyślnego wprowadzenia luk w zabezpieczeniach lub złośliwego kodu. Zawsze sprawdzaj wiarygodność stron trzecich, najlepiej jak potrafisz, i umieszczaj linki do wszystkich kodów stron trzecich za pomocą protokołu HTTPS. Na koniec upewnij się, że korzyści płynące z wszelkich elementów stron trzecich w Twojej witrynie są warte ryzyka.

Sprawdź swoją pracę za pomocą narzędzi diagnostycznych

Po skonfigurowaniu SSL /TLS na serwerze i stronie internetowej lub dokonując jakichkolwiek zmian w konfiguracji, ważne jest, aby upewnić się, że wszystko jest poprawnie skonfigurowane, a system jest bezpieczny. Dostępnych jest wiele narzędzi diagnostycznych do sprawdzania SSL witryny /TLS. Na przykład SSL Shopper's Sprawdzanie SSL poinformuje Cię, czy Twój certyfikat został poprawnie zainstalowany, kiedy wygaśnie i wyświetli certyfikat łańcuch zaufania.

Dostępne są inne narzędzia i aplikacje internetowe, które będą indeksować witrynę w poszukiwaniu problemów bezpieczeństwa, takich jak mieszana zawartość. Możesz także sprawdzić zawartość mieszaną za pomocą przeglądarki internetowej, korzystając z wbudowanych narzędzi programistycznych:

ostrzeżenie o mieszanej zawartości
Ostrzeżenie o mieszanej zawartości w konsoli Chrome

Niezależnie od wybranych narzędzi ważne jest również ustalenie harmonogramu sprawdzania SSL /TLS instalacja i konfiguracja. Twój CA również może Ci w tym pomóc; na przykład, dla wygody naszych klientów, SSL.com zapewnia automatyczne powiadomienia o zbliżającym się wygaśnięciu certyfikatu.


Wdrożenie ścisłych zabezpieczeń transportu HTTP (HSTS)

HTTP Strict Transport Security (HSTS) to mechanizm polityki bezpieczeństwa, który pomaga chronić strony internetowe przed atakami obniżającymi poziom protokołu i przejmowaniem plików cookie. Pozwala serwerom WWW zadeklarować, że przeglądarki internetowe (lub inne zgodne programy użytkownika) powinny wchodzić z nim w interakcję tylko za pomocą bezpiecznych połączeń HTTPS, a nigdy za pośrednictwem niezabezpieczonego protokołu HTTP. Ta polityka jest przekazywana przez serwer do klienta użytkownika za pośrednictwem pola nagłówka odpowiedzi HTTP o nazwie „Strict-Transport-Security”.

Aby wdrożyć Ścisłe zabezpieczenia transportu HTTP (HSTS), musisz dodać specjalny nagłówek odpowiedzi do konfiguracji swojego serwera WWW.

Oto przewodnik krok po kroku:

  1. Upewnij się, że Twoja witryna obsługuje protokół HTTPS: przed włączeniem HSTS witryna musi mieć prawidłowy plik certyfikat SSL i mieć możliwość udostępniania treści przez HTTPS. Jeśli Twoja witryna nie jest jeszcze skonfigurowana do obsługi protokołu HTTPS, musisz to zrobić uzyskać certyfikat SSL i skonfiguruj swój serwer, aby z niego korzystał.
Nagłówek zawsze ustawia Strict-Transport-Security „max-age=31536000; includeSubDomains”

Ten wiersz mówi przeglądarce, aby zawsze używała HTTPS w Twojej witrynie przez następny rok (31,536,000 XNUMX XNUMX sekund), w tym wszystkie subdomeny.

 

  1. Przetestuj swoją konfigurację: po dodaniu nagłówka HSTS należy przetestować witrynę, aby upewnić się, że działa poprawnie. Możesz to zrobić, odwiedzając swoją witrynę i korzystając z narzędzi programistycznych przeglądarki, aby sprawdzić nagłówki odpowiedzi. Powinieneś zobaczyć nagłówek Strict-Transport-Security z ustawioną wartością.
  2. Rozważ dodanie witryny do listy wstępnego ładowania HSTS: lista wstępnego ładowania HSTS to lista witryn, które są zakodowane na stałe w przeglądarkach jako obsługujące HSTS. Zapewnia to dodatkowy poziom ochrony, ponieważ gwarantuje, że pierwsze połączenie z witryną jest bezpieczne, nawet przed odebraniem nagłówka HSTS. Możesz zgłosić swoją witrynę do listy wstępnego ładowania HSTS na stronie hstspreload.org.

 

Przypadek użycia: Witryna z wiadomościami chce mieć pewność, że jej użytkownicy zawsze bezpiecznie się z nią łączą, nawet jeśli przypadkowo wpiszą „http” zamiast „https” w adresie URL. Witryna korzysta z HSTS, dodając nagłówek Strict-Transport-Security do konfiguracji serwera, ustawiając długi maksymalny wiek i uwzględniając wszystkie subdomeny. To mówi agencjom użytkownika, aby zawsze łączył się z nim za pomocą HTTPS, chroniąc użytkowników przed atakami próbującymi obniżyć wersję połączenia do HTTP i ukraść ich pliki cookie. Witryna zgłasza się również na listę wstępnego ładowania HSTS w celu dodatkowej ochrony.

Zaimplementuj przypinanie klucza publicznego HTTP (HPKP)

Przypinanie klucza publicznego HTTP (HPKP) było funkcją bezpieczeństwa, która umożliwiała serwerowi sieciowemu powiązanie ze sobą określonego kryptograficznego klucza publicznego w celu zapobieżenia ataki typu man-in-the-middle (MITM) ze sfałszowanymi certyfikatami.

Oto krótki przegląd tego, jak był używany:

  1. Wygeneruj informacje o przypinaniu: Pierwszym krokiem we wdrażaniu HPKP było wygenerowanie informacji o przypinaniu. Wiązało się to z utworzeniem kryptograficznego skrótu klucza publicznego certyfikatu lub klucza publicznego certyfikatu pośredniego lub głównego.
  2. Skonfiguruj serwer WWW: Następnym krokiem było skonfigurowanie serwera WWW tak, aby zawierał Klucze publiczne HTTP nagłówek w odpowiedziach. Ten nagłówek zawierał skróty kluczy publicznych („szpilki”), czas życia (jak długo przeglądarka powinna zapamiętać informacje) i opcjonalnie identyfikator URI raportu (do którego przeglądarka wysyłała raporty o niepowodzeniach sprawdzania poprawności kodu PIN).
  3. Obsługa błędów sprawdzania poprawności kodu PIN: jeśli przeglądarka obsługująca HPKP otrzyma łańcuch certyfikatów, który nie zawiera co najmniej jednego z przypiętych kluczy publicznych, uzna połączenie za niezaufane. Jeśli określono identyfikator URI raportu, przeglądarka wyśle ​​również raport o niepowodzeniu do tego identyfikatora URI.

 

Jednak ze względu na ryzyko niewłaściwego użycia i możliwość spowodowania odmowy usługi, HPKP zostało uznane za przestarzałe przez większość przeglądarek i nie jest już zalecaną praktyką. Błędna konfiguracja HPKP może doprowadzić do sytuacji, w której strona internetowa stanie się niedostępna.

Przypadek użycia: W przeszłości firma technologiczna używała HPKP do przypinania swoich kluczy publicznych do swoich serwerów. Gwarantowało to, że jeśli urząd certyfikacji (CA) został naruszony i przez pomyłkę został wydany certyfikat dla ich domeny, przeglądarki nie zaufałyby mu, chyba że miałby on również klucz publiczny pasujący do jednego z przypiętych kluczy. Musieli jednak bardzo uważać, aby nie utracić dostępu do przypiętych kluczy, co uniemożliwiłoby dostęp do ich strony internetowej. Musieli również upewnić się, że wdrożyli proces rotacji pinezek przed ich wygaśnięciem, aby uniknąć sytuacji, w której ich witryna byłaby niedostępna dla użytkowników z buforowanymi informacjami o przypinaniu.

SSL.com zapewnia szeroką gamę SSL/TLS certyfikaty serwera. Zabezpiecz swoją witrynę już dziś za pomocą certyfikatu SSL z SSL.com i buduj zaufanie wśród odwiedzających!

PORÓWNAJ SSL /TLS CERTYFIKATY

Zastosowanie TLS Fallback SCSV, aby zapobiec atakom na obniżenie wersji protokołu

TLS Rezerwowy SCSV (Wartość zestawu szyfrów sygnalizacyjnych) to mechanizm, który został wprowadzony w celu zapobiegania atakom na obniżenie wersji protokołu. Ataki te mają miejsce, gdy osoba atakująca ingeruje w proces konfiguracji połączenia i nakłania klienta i serwer do korzystania z mniej bezpiecznej wersji protokołu, niż ta, którą faktycznie obsługują.

Oto jak możesz wdrożyć TLS Zastępczy SCSV:

  1. Zaktualizuj SSL/TLS Biblioteka: Pierwszym krokiem jest upewnienie się, że SSL/TLS wsporniki biblioteczne TLS Rezerwowy SCSV. Ta funkcja została wprowadzona w OpenSSL 1.0.1j, 1.0.0o i 0.9.8zc. Jeśli używasz innego protokołu SSL/TLS bibliotekę, sprawdź jej dokumentację lub skontaktuj się z jej twórcami.
  2. Skonfiguruj swój serwer: Po nawiązaniu połączenia SSL/TLS wsporniki biblioteczne TLS Fallback SCSV, może być konieczne skonfigurowanie serwera, aby z niego korzystał. Dokładne kroki będą zależeć od oprogramowania serwera. Na przykład w Apache może być konieczne dodanie lub zmodyfikowanie wiersza w pliku konfiguracyjnym w następujący sposób:

 

Protokół SSL Wszystkie -SSLv2 -SSLv3

Ta linia mówi serwerowi, aby używał wszystkich wersji protokołów z wyjątkiem SSLv2 i SSLv3. Jeśli zarówno klient, jak i serwer obsługują TLS 1.2, ale klient próbuje użyć TLS 1.1 (być może z powodu ingerencji atakującego), serwer rozpozna to jako próbę powrotu i odrzuci połączenie.

  1. Przetestuj swój serwer: Po skonfigurowaniu serwera należy go przetestować, aby upewnić się, że działa poprawnie TLS Rezerwowy SCSV. Istnieją różne narzędzia online, które mogą ci w tym pomóc, takie jak test serwera SSL Labs.

 

Przypadek użycia: Używa globalna korporacja TLS Fallback SCSV w celu ochrony komunikacji wewnętrznej. Gwarantuje to, że jeśli atakujący spróbuje wymusić obniżenie wersji protokołu, serwer rozpozna to i odrzuci połączenie, chroniąc poufne dane korporacji. Zespół IT korporacji regularnie aktualizuje certyfikaty SSL/TLS bibliotek i konfiguracji, aby upewnić się, że używają najnowszych funkcji bezpieczeństwa, a także używają narzędzi online do testowania swoich serwerów i potwierdzania, że ​​wdrażają one poprawnie TLS Rezerwowy SCSV.

Unikaj problemów z mieszaną zawartością

Zawartość mieszana stanowi zagrożenie bezpieczeństwa, które pojawia się, gdy strona internetowa ładowana przez bezpieczne połączenie HTTPS zawiera zasoby, takie jak obrazy, wideo, arkusze stylów lub skrypty, które są ładowane przez niezabezpieczone połączenie HTTP. Przeglądarki mogą blokować tę mieszaną zawartość lub wyświetlać użytkownikowi ostrzeżenie, co może zaszkodzić jego postrzeganiu bezpieczeństwa witryny.

Oto jak możesz uniknąć problemów z mieszaną zawartością:

  1. Użyj HTTPS dla wszystkich zasobów: najprostszym sposobem uniknięcia mieszanych treści jest upewnienie się, że wszystkie zasoby w Twojej witrynie są ładowane przez HTTPS. Obejmuje to obrazy, skrypty, arkusze stylów, ramki iframe, żądania AJAX i wszelkie inne zasoby używane przez Twoją witrynę.
  2. Zaktualizuj kod swojej witryny: jeśli kod Twojej witryny zawiera zakodowane na stałe adresy URL HTTP zasobów, musisz je zaktualizować, aby zamiast tego używać protokołu HTTPS. Jeśli zasób jest hostowany na serwerze, który nie obsługuje HTTPS, może być konieczne hostowanie zasobu na własnym serwerze lub znalezienie alternatywnego zasobu, który można załadować przez HTTPS.
  3. Skonfiguruj swój serwer, aby wysyłał nagłówek Content-Security-Policy: Nagłówek HTTP Content-Security-Policy (CSP) pozwala kontrolować zasoby, które witryna może ładować. Ustawiając nagłówek CSP, który zezwala tylko na zasoby HTTPS, możesz mieć pewność, że Twoja witryna nie zawiera przypadkowo treści mieszanych.

 

Przypadek użycia: magazyn internetowy gwarantuje, że wszystkie treści, w tym obrazy i skrypty, są ładowane przez HTTPS. Uniemożliwia to osobom atakującym modyfikowanie tych zasobów i potencjalnie wprowadzanie złośliwej zawartości. Twórcy stron internetowych magazynu regularnie przeglądają kod witryny, aby upewnić się, że wszystkie zasoby są ładowane przez HTTPS, i konfigurują swój serwer tak, aby wysyłał ścisły nagłówek Content-Security-Policy. Używają również narzędzi online do skanowania witryny pod kątem problemów z mieszaną zawartością i naprawiania wszelkich znalezionych problemów.

Wykorzystaj wskazanie nazwy serwera (SNI) do hostowania wielu witryn

Wskazanie nazwy serwera (SNI) jest rozszerzeniem do TLS protokół, który umożliwia serwerowi przedstawianie wielu certyfikatów na tym samym adresie IP i numerze portu. Jest to szczególnie przydatne dla dostawców usług hostingowych, którzy muszą hostować wiele bezpiecznych witryn internetowych, z których każda ma własny certyfikat SSL, na tym samym serwerze.

Oto jak możesz użyć SNI:

  1. Upewnij się, że oprogramowanie Twojego serwera obsługuje SNI: Pierwszym krokiem jest upewnienie się, że oprogramowanie serwera obsługuje SNI. Większość nowoczesnych serwerów internetowych, w tym Apache, Nginx i IIS, obsługuje SNI.
  2. Skonfiguruj swój serwer: Następnym krokiem jest skonfigurowanie serwera do korzystania z SNI. Zwykle wymaga to dodania oddzielnego bloku konfiguracji dla każdej witryny, którą chcesz hostować na serwerze, oraz określenia certyfikat SSL do użycia dla każdej witryny. Dokładne kroki będą zależeć od oprogramowania serwera.
  3. Przetestuj swoją konfigurację: Po skonfigurowaniu serwera należy go przetestować, aby upewnić się, że poprawnie korzysta z SNI. Możesz to zrobić, odwiedzając każdą witrynę hostowaną na serwerze i sprawdzając, czy używany jest prawidłowy certyfikat SSL.

 

Przypadek użycia: Dostawca usług hostingowych używa SNI do obsługi wielu stron internetowych z tego samego adresu IP. Pozwala im to na efektywne wykorzystanie przestrzeni adresowej IP i uproszczenie konfiguracji sieci. Konfigurują swój serwer tak, aby używał innego certyfikatu SSL dla każdej witryny i regularnie testują swoją konfigurację, aby upewnić się, że dla każdej witryny używany jest właściwy certyfikat. Dzięki temu każda witryna ma bezpieczne, zaufane połączenie, nawet jeśli wszystkie są obsługiwane z tego samego adresu IP.

Zoptymalizuj wydajność dzięki wznawianiu sesji

Wznawianie sesji jest cechą TLS protokół, który umożliwia klientowi i serwerowi używanie tych samych kluczy szyfrowania w wielu sesjach, zmniejszając obciążenie związane z ustanawianiem nowego bezpiecznego połączenia za każdym razem. Może to znacznie poprawić wydajność, szczególnie w przypadku aplikacji, w których klient często się rozłącza i ponownie łączy.

 Oto jak możesz użyć wznawiania sesji:

  1. Upewnij się, że oprogramowanie Twojego serwera obsługuje wznawianie sesji: Pierwszym krokiem jest upewnienie się, że oprogramowanie serwera obsługuje wznawianie sesji. Większość nowoczesnych serwerów internetowych, w tym Apache, Nginx i IIS, obsługuje tę funkcję.
  2. Skonfiguruj swój serwer: Następnym krokiem jest skonfigurowanie serwera do wznawiania sesji. Zwykle obejmuje to włączenie pamięci podręcznej sesji i ustawienie wartości limitu czasu dla pamięci podręcznej. Dokładne kroki będą zależeć od oprogramowania serwera.
  3. Przetestuj swoją konfigurację: Po skonfigurowaniu serwera należy go przetestować, aby upewnić się, że prawidłowo korzysta ze wznawiania sesji. Możesz to zrobić, ustanawiając TLS połączenie z serwerem, rozłączenie, a następnie ponowne połączenie. Jeśli wznawianie sesji działa poprawnie, drugie połączenie powinno być szybsze niż pierwsze.

 

Przypadek użycia: aplikacja mobilna używa wznawiania sesji w celu utrzymania szybkich i bezpiecznych połączeń. Jest to szczególnie przydatne, gdy aplikacja jest używana w obszarach o nieregularnym zasięgu sieci, ponieważ umożliwia aplikacji szybkie przywrócenie bezpiecznego połączenia po zerwaniu. Twórcy aplikacji konfigurują swój serwer do wznawiania sesji i regularnie testują tę funkcję, aby upewnić się, że działa poprawnie. Dzięki temu aplikacja może zapewnić użytkownikom szybkie i bezproblemowe działanie, nawet w trudnych warunkach sieciowych.

 

Zapewnij ważność certyfikatu dzięki funkcji zszywania OCSP

Stapling Online Certificate Status Protocol (OCSP) to metoda poprawy wydajności protokołu SSL/TLS przy zachowaniu bezpieczeństwa połączenia. Pozwala serwerowi pobierać aktualny stan własnych certyfikatów z urzędu certyfikacji (CA), a następnie dostarczać ten status klientom podczas TLS uścisk dłoni.

Oto jak można zaimplementować zszywanie OCSP:

  1. Upewnij się, że oprogramowanie Twojego serwera obsługuje zszywanie OCSP: Pierwszym krokiem jest upewnienie się, że oprogramowanie serwera obsługuje zszywanie OCSP. Większość nowoczesnych serwerów internetowych, w tym Apache, Nginx i IIS, obsługuje tę funkcję.
  2. Skonfiguruj swój serwer: Następnym krokiem jest skonfigurowanie serwera do używania zszywania OCSP. Zwykle wiąże się to z włączeniem tej funkcji w protokołach SSL/TLS konfigurację i określenie lokalizacji serwera do przechowywania odpowiedzi OCSP. Dokładne kroki będą zależeć od oprogramowania serwera.
  3. Przetestuj swoją konfigurację: Po skonfigurowaniu serwera należy go przetestować, aby upewnić się, że poprawnie korzysta ze zszywania OCSP. Możesz to zrobić, ustanawiając TLS połączenie z serwerem i sprawdzenie, czy serwer zawiera odpowiedź OCSP w pliku TLS uścisk dłoni.

 

Przypadek użycia: sprzedawca internetowy używa zszywania OCSP, aby szybko zweryfikować stan swojego certyfikatu SSL. Dzięki temu klienci zawsze mają bezpieczne połączenie i mogą ufać, że ich dane są bezpieczne. Zespół IT sprzedawcy konfiguruje serwer do używania zszywania OCSP i regularnie testuje tę funkcję, aby upewnić się, że działa poprawnie. Pomaga to utrzymać zaufanie klientów i chronić ich wrażliwe dane.

 

Wyłącz TLS Kompresja w celu złagodzenia ataku CRIME

TLS kompresja to funkcja, która może poprawić wydajność protokołu SSL/TLS poprzez zmniejszenie ilości danych, które muszą być przesłane przez sieć. Jednak może również narazić połączenie na atak CRIME (Compression Ratio Info-leak Made Easy), który może pozwolić atakującemu na wywnioskowanie zawartości zaszyfrowanego ruchu.

Oto jak możesz wyłączyć TLS kompresja: 

  1. Upewnij się, że oprogramowanie Twojego serwera obsługuje wyłączanie TLS Kompresja: Pierwszym krokiem jest upewnienie się, że oprogramowanie serwera obsługuje wyłączanie TLS kompresja. Większość nowoczesnych serwerów internetowych, w tym Apache, Nginx i IIS, obsługuje tę funkcję.
  2. Skonfiguruj swój serwer: Następnym krokiem jest skonfigurowanie wyłączenia serwera TLS kompresja. Dokładne kroki będą zależeć od oprogramowania serwera. Na przykład w Apache możesz dodać taką linię do pliku konfiguracyjnego:
SSLKompresja wyłączona

Ta linia mówi serwerowi, aby nie używał kompresji dla SSL/TLS połączeń.

  1. Przetestuj swoją konfigurację: Po skonfigurowaniu serwera należy go przetestować, aby upewnić się, że prawidłowo się wyłącza TLS kompresja. Możesz to zrobić, ustanawiając TLS połączenie z serwerem i sprawdzenie, czy połączenie nie korzysta z kompresji.

 

Przypadek użycia: Instytucja finansowa wyłącza TLS kompresji na swoich serwerach w celu ochrony przed atakiem CRIME. Pomaga to zapewnić poufność wrażliwych danych finansowych, takich jak numery kont i szczegóły transakcji. Zespół IT instytucji konfiguruje swoje serwery do wyłączenia TLS kompresji i regularnie testują serwery, aby upewnić się, że prawidłowo wdrażają ten środek bezpieczeństwa. Pomaga to chronić klientów instytucji i utrzymać ich zaufanie.

Wdrożenie TLS Bilety na sesje poprawnie

TLS bilety sesyjne są cechą TLS protokół, który może poprawić wydajność, umożliwiając klientowi i serwerowi wznowienie poprzedniej sesji bez konieczności pełnego uzgadniania. Muszą być jednak poprawnie zaimplementowane, aby uniknąć potencjalnych problemów z bezpieczeństwem.

Oto jak możesz poprawnie wdrożyć TLS bilety na sesję:

  1. Upewnij się, że oprogramowanie Twojego serwera jest obsługiwane TLS Bilety sesyjne: Pierwszym krokiem jest upewnienie się, że oprogramowanie serwera obsługuje TLS bilety sesyjne. Większość nowoczesnych serwerów internetowych, w tym Apache, Nginx i IIS, obsługuje tę funkcję.
  2. Skonfiguruj swój serwer: Następnym krokiem jest skonfigurowanie serwera do użycia TLS bilety sesyjne. Zwykle wiąże się to z włączeniem tej funkcji w protokołach SSL/TLS konfiguracja. Dokładne kroki będą zależeć od oprogramowania serwera.
  3. Użyj unikalnych kluczy biletu sesji: Aby zapobiec potencjalnym problemom z bezpieczeństwem, każdy serwer powinien używać unikalnego klucza biletu sesji. Jeśli korzystasz z systemu równoważenia obciążenia, skonfiguruj go tak, aby dystrybuował klientów na podstawie ich biletu sesji, zamiast zezwalać klientom na używanie biletu sesji wystawionego przez jeden serwer w celu ustanowienia sesji z innym serwerem.
  4. Regularnie zmieniaj klucze do biletów sesji: Aby jeszcze bardziej zwiększyć bezpieczeństwo, należy regularnie wymieniać klucze do biletów sesji. Często można to zautomatyzować za pomocą oprogramowania serwera lub oddzielnego systemu zarządzania kluczami.

 

Przypadek użycia: Duża firma technologiczna z wieloma serwerami zapewnia, że ​​każdy serwer używa unikalnego klucza biletu sesji. Uniemożliwia to osobie atakującej użycie biletu sesji z jednego serwera do podszywania się pod użytkownika na innym serwerze. Zespół IT firmy konfiguruje swoje serwery do użycia TLS biletów sesyjnych i stworzyli system regularnej rotacji kluczy biletów sesyjnych. Konfigurują również swój system równoważenia obciążenia, aby dystrybuować klientów na podstawie ich biletu sesji, jeszcze bardziej zwiększając bezpieczeństwo ich systemu.

Włącz bezpieczną renegocjację

Bezpieczna renegocjacja jest cechą protokołu SSL/TLS protokoły, które pozwalają klientowi lub serwerowi zażądać nowego TLS uścisk dłoni w środku sesji. Może to być przydatne z różnych powodów, takich jak odświeżenie kluczy szyfrowania lub zmiana poziomu szyfrowania. Jeśli jednak nie jest obsługiwany w bezpieczny sposób, atakujący może wykorzystać go do wstrzyknięcia zwykłego tekstu do zaszyfrowanej komunikacji.

Oto jak włączyć bezpieczną renegocjację:

  1. Upewnij się, że oprogramowanie Twojego serwera obsługuje bezpieczną renegocjację: Pierwszym krokiem jest upewnienie się, że oprogramowanie serwera obsługuje bezpieczną renegocjację. Większość nowoczesnych serwerów internetowych, w tym Apache, Nginx i IIS, obsługuje tę funkcję.
  2. Skonfiguruj swój serwer: Następnym krokiem jest skonfigurowanie serwera do korzystania z bezpiecznej renegocjacji. Zwykle wiąże się to z włączeniem tej funkcji w protokołach SSL/TLS konfiguracja. Dokładne kroki będą zależeć od oprogramowania serwera.
  3. Przetestuj swoją konfigurację: Po skonfigurowaniu serwera należy go przetestować, aby upewnić się, że poprawnie korzysta z bezpiecznej renegocjacji. Możesz to zrobić, ustanawiając TLS połączenie z serwerem, a następnie próba renegocjacji połączenia.

 

Przypadek użycia: Platforma mediów społecznościowych umożliwia bezpieczne renegocjacje w celu ochrony danych użytkowników. Uniemożliwia to atakującemu wstrzyknięcie złośliwej zawartości do zaszyfrowanej komunikacji między użytkownikiem a serwerem. Zespół IT platformy konfiguruje swoje serwery do korzystania z bezpiecznej renegocjacji i regularnie testuje serwery, aby upewnić się, że prawidłowo wdrażają ten środek bezpieczeństwa. Pomaga to chronić użytkowników platformy i utrzymać ich zaufanie.

Wyłącz renegocjację inicjowaną przez klienta, aby zapobiec atakom DoS

Renegocjacja inicjowana przez klienta jest funkcją protokołu SSL/TLS protokoły, które pozwalają klientowi zażądać nowego TLS uścisk dłoni w środku sesji. Jeśli jednak osoba atakująca może zmusić serwer do ciągłej renegocjacji sesji, może to spowodować nadmierne zużycie zasobów i potencjalnie doprowadzić do ataku typu „odmowa usługi” (DoS).

Oto jak możesz wyłączyć renegocjację inicjowaną przez klienta:

  1. Upewnij się, że oprogramowanie Twojego serwera obsługuje wyłączenie renegocjacji inicjowanych przez klienta: Pierwszym krokiem jest upewnienie się, że oprogramowanie serwera obsługuje wyłączenie renegocjacji inicjowanej przez klienta. Większość nowoczesnych serwerów internetowych, w tym Apache, Nginx i IIS, obsługuje tę funkcję.
  2. Skonfiguruj swój serwer: Następnym krokiem jest skonfigurowanie serwera w celu wyłączenia renegocjacji inicjowanych przez klienta. Zwykle wiąże się to z dodaniem dyrektywy do protokołu SSL/TLS konfiguracja. Dokładne kroki będą zależeć od oprogramowania serwera.
  3. Przetestuj swoją konfigurację: Po skonfigurowaniu serwera należy go przetestować, aby upewnić się, że poprawnie wyłącza renegocjację inicjowaną przez klienta. Możesz to zrobić, ustanawiając TLS połączenie z serwerem, a następnie próba renegocjacji połączenia. Jeśli serwer prawidłowo odrzuci żądanie renegocjacji, oznacza to, że jest poprawnie skonfigurowany.

 

Przypadek użycia: Platforma gier online wyłącza inicjowane przez klienta renegocjacje w celu ochrony przed potencjalnymi atakami DoS. Pomaga to zapewnić, że platforma pozostaje dostępna dla użytkowników, nawet w obliczu potencjalnych ataków. Zespół IT platformy konfiguruje swoje serwery, aby wyłączyć renegocjację inicjowaną przez klienta, i regularnie testuje serwery, aby upewnić się, że prawidłowo wdrażają ten środek bezpieczeństwa. Pomaga to chronić użytkowników platformy i utrzymać ich zaufanie.

Bądź czujny na nowe luki

Bezpieczeństwo sieci jest ciągle zmieniającym się celem i zawsze powinieneś uważać na następny atak i niezwłocznie stosować łaty bezpieczeństwa na swoim serwerze. Oznacza to czytanie i pozostawanie w kontakcie z tym, co jest na horyzoncie, jeśli chodzi o bezpieczeństwo informacji, a także śledzenie aktualizacji oprogramowania - zwłaszcza tych krytycznych. Witryna SSL.com (tam, gdzie to teraz czytasz) jest doskonałym źródłem aktualności na temat SSL /TLS i bezpieczeństwo informacji.

Ale co z…?

Jeśli chcesz dowiedzieć się więcej na którykolwiek z tematów omówionych w tym przewodniku i dowiedzieć się o nowych problemach i technologiach w miarę ich pojawiania się, możesz zacząć od przeglądania i przeszukiwania witryn SSL.com Baza wiedzy, o którym co tydzień informujemy o nowych osiągnięciach w dziedzinie SSL /TLS i PKI. Możesz również skontaktować się z naszym personelem wsparcia w dowolnym momencie za pośrednictwem poczty elektronicznej na adres Support@SSL.com, telefonicznie o godz 1-877-SSL-Securelub klikając łącze czatu w prawym dolnym rogu tej strony.

SSL.com zapewnia szeroką gamę domen SSL /TLS certyfikaty serwera dla witryn HTTPS.

PORÓWNAJ SSL /TLS CERTYFIKATY

 

Uzyskaj porady ekspertów na temat certyfikatów SSL.
Wypełnij formularz na konsultację.

Twitter
Facebook
LinkedIn
Reddit
E-mail