Zabezpieczenia warstwy transportowej (TLS) jest podstawowym środkiem ochrony komunikacji sieciowej w Internecie. Ten artykuł jest krótkim przewodnikiem, który pomoże Ci skonfigurować bezpieczny serwer zgodnie z aktualnymi TLS standardy.
Wprowadzenie
Połączenia Zabezpieczenia warstwy transportowej (TLS) Protokół jest podstawowym środkiem ochrony komunikacji sieciowej przez Internet. To (i jego poprzednik, Secure Sockets Layer lub SSL) były używane od dziesięcioleci w wielu aplikacjach, ale przede wszystkim w przeglądarkach podczas ich odwiedzania HTTPS strony internetowe. TLS zwykle działa cicho w tle, ale wbrew temu, co mogłoby się wydawać, TLS nie jest czarną skrzynką, która po prostu działa. Raczej bezpieczeństwo TLS zapewnia wynika ze współpracy różnych algorytmów kryptograficznych. Ponadto, TLSPodobnie jak wcześniej SSL, stale ewoluuje wraz z branżą bezpieczeństwa - nowe technologie i wymagania biznesowe muszą być spełnione, a najnowsze zagrożenia bezpieczeństwa muszą być łagodzone. Algorytmy mogą z czasem stać się przestarzałe lub praktyki mogą zostać zarzucone, a każda zmiana wpływa na ogólne bezpieczeństwo TLS instancja (jak ta, która teraz chroni twoje połączenie).
Ta zmienność zmotywowała różne organizacje normalizacyjne do opublikowania dokumentów zawierających wytyczne, tak aby była to minimalna podstawa dla TLS bezpieczeństwo można ustanowić na określonym rynku, sektorze lub usłudze. Niestety istnieje wiele takich standardów, przy czym różne sektory wymagają zgodności z różnymi mającymi zastosowanie dokumentami, a same normy również ewoluują z czasem, dostosowując się do zmian w sektorze, który mają chronić.
Zrozumiałe jest poruszanie się po morzu standardów w celu stworzenia nowoczesnego TLS instancja może być prawdziwym bólem głowy dla administratorów. Ten artykuł jest krótkim przewodnikiem, który pomoże Ci skonfigurować bezpieczny serwer zgodnie z oczekiwaniami TLS standardów w 2021 roku. (Aby uzyskać dalszą pomoc, podaliśmy również przykładowe konfiguracje najpopularniejszych rozwiązań serwerowych w dodatek.)
Standardy
Istnieje kilka podmiotów, które utrzymują wytyczne dla TLS w odniesieniu do bezpieczeństwa sieci, na przykład Departament Zdrowia i Opieki Społecznej Stanów Zjednoczonych (HHS) lub National Institute of Standards and Technology (NIST). Ze względu na zwięzłość w tym artykule przeanalizujemy tylko trzy najczęściej przyjmowane dokumenty:
- Połączenia Ustawa dotycząca przenośności i odpowiedzialności w zakresie ubezpieczeń społecznych (HIPAA)
- NIST Wytyczne SP 800-52r2
- Połączenia Karta płatnicza Standard bezpieczeństwa danych branżowych (PCI-DSS)
HIPAA
HIPAA to rozporządzenie uchwalone przez rząd USA w 1996 r., Dotyczące bezpiecznego postępowania z Chronione informacje zdrowotne (PHI). PHI odnosi się do wszelkich cyfrowych informacji o pacjencie, takich jak wyniki testów lub diagnozy. HIPAA dokument z wytycznymi opublikowany w 2013 roku stwierdza, co następuje:
Prawidłowe procesy szyfrowania danych w ruchu to te, które są zgodne, odpowiednio, z publikacjami specjalnymi NIST 800-52, Wytycznymi dotyczącymi wyboru i stosowania zabezpieczeń warstwy transportowej (TLS) Wdrożenia; 800-77, Przewodnik po sieciach VPN IPsec; lub 800-113, Przewodnik po SSL VPN lub inne, które są zatwierdzone przez Federal Information Processing Standards (FIPS) 140-2.
Standardy NIST
W 2005 r. NIST opublikował specjalną publikację (SP) 800-52, opisującą prawidłowe procedury operacyjne w celu bezpiecznego skonfigurowania TLS przykład dla serwerów rządowych. Od tego czasu SP 800-52 został zastąpiony wersjami SP 800-52r1 (2014) i SP 80052r2 (2019). Ten artykuł jest zgodny z wytycznymi SP 800-52r2, który jest obecnie stabilny.
PCI DSS
PCI-DSS to standard zgodności utrzymywany przez Radę ds. Bezpieczeństwa Standardów Kart Płatniczych (PCI), która określa, w jaki sposób informacje o płatnościach i kartach są obsługiwane przez strony internetowe handlu elektronicznego. Odnośnie właściwej konfiguracji TLS instancje, stany PCI-DSS:
„Zapoznaj się ze standardami branżowymi i najlepszymi praktykami, aby uzyskać informacje na temat silnej kryptografii i bezpiecznych protokołów (np. NIST SP 800-52 i SP 800-57, OWASP itp.)”
TLS standardy: składając je wszystkie razem
Należy już zauważyć, że każdy standard ma wpływ na różne systemy, w zależności od ich funkcji i obsługiwanych danych. Na przykład szpitalny serwer poczty e-mail może podlegać wytycznym HIPAA, ponieważ wymieniane wiadomości mogą zawierać informacje o pacjencie, podczas gdy szpitalny system CRM może podlegać PCI-DSS, ponieważ może zawierać dane kart kredytowych i inne dane klientów. Zgodność ze wszystkimi trzema standardami wymagałaby zastosowania wspólnego TLS parametry obecne we wszystkich dokumentach.
Na szczęście jest oczywiste, że wszystkie standardy są zgodne z wytycznymi NIST dotyczącymi doboru TLS parametry Oznacza to, że w momencie pisania tego tekstu zgodność z SP 800-52r2 powinna również zapewnić zgodność serwera z HIPAA i PCI-DSS. (Okej, to nie jest dokładnie to prawda, ale w następnej sekcji wszystko się wyjaśni.)
konfigurowalny TLS parametry
Poziom bezpieczeństwa, który TLS zapewnia największy wpływ na wersja protokołu (tj. 1.0, 1.1 itd.) i dozwolone zestawy szyfrów. Szyfry to algorytmy, które wykonują szyfrowanie i deszyfrowanie. Jednak zestaw szyfrów to zestaw algorytmów, w tym szyfr, algorytm wymiany kluczy i algorytm mieszający, które są używane razem w celu ustanowienia bezpiecznego TLS połączenie. Większość TLS klienci i serwery obsługują wiele alternatyw, więc muszą negocjować podczas ustanawiania bezpiecznego połączenia, aby wybrać wspólne TLS wersja i pakiet szyfrów.
TLS wersja protokołu
O TLS obsługa wersji, NIST SP 800-52r2 stwierdza, co następuje:
Serwery obsługujące aplikacje rządowe powinien być skonfigurowany do użycia TLS 1.2 i powinien być skonfigurowany do użycia TLS 1.3 również. Te serwery nie powinien być skonfigurowany do użycia TLS 1.1 i nie można posługiwać się TLS 1.0, SSL 3.0 lub SSL 2.0.
...
Serwery obsługujące aplikacje obywatelskie lub biznesowe (np. Klient nie może być częścią rządowego systemu informatycznego) powinien być skonfigurowany do negocjacji TLS 1.2 i powinien być skonfigurowany do negocjacji TLS 1.3. Sposób użycia TLS wersje 1.1 i 1.0 są generalnie odradzane, ale te wersje mogą być konfigurowane w razie potrzeby, aby umożliwić interakcję z obywatelami i firmami… Te serwery nie można zezwalają na używanie SSL 2.0 lub SSL 3.0.
Oddziały powinien wsparcie TLS 1.3 do 1 stycznia 2024 r. Po tej dacie serwery powinien wsparcie TLS 1.3 zarówno dla aplikacji rządowych, jak i dla obywateli lub firm. Ogólnie serwery obsługujące TLS 1.3 powinien być skonfigurowany do użycia TLS 1.2 jak również. Jednak, TLS 1.2 może być wyłączone na serwerach, które obsługują TLS 1.3 jeśli zostało to ustalone TLS 1.2 nie jest potrzebne do interoperacyjności.
Kompletujemy wszystkie dokumenty (wymagana jest kopia paszportu i XNUMX zdjęcia) potrzebne do TLS 1.0 jest zabronione i TLS 1.1 jest przestarzałe w przypadku witryn rządowych, wytyczne NIST stwierdzają, że w celu zapewnienia zgodności z usługami stron trzecich serwery kontrolowane przez rząd może wdrożenia TLS 1.0 i 1.1 w razie potrzeby. W ramach PCI-DSS 3.2.1 (aktualna wersja), zgodne serwery musi porzucić wsparcie dla TLS 1.0 i „migruj do minimum TLS 1.1, najlepiej TLS 1.2. ” HIPAA technicznie zezwala na używanie wszystkich wersji TLS. Zatem minimum powszechnie obsługiwane TLS wersja to 1.1; jednak PCI-DSS i NIST zdecydowanie sugerują użycie bezpieczniejszych TLS 1.2 (i, jak widać powyżej, NIST zaleca przyjęcie TLS 1.3 i planuje wymagać wsparcia do 2024 r.).
Zestawy szyfrów
TLS 1.2 i starsze
SP 800-52r2 określa różne dopuszczalne zestawy szyfrów dla TLS 1.2 i starsze. Standard nie wymaga obsługi żadnego konkretnego zestawu szyfrów, ale oferuje wskazówki dotyczące wyboru silniejszych:
- Preferuj klucze efemeryczne od kluczy statycznych (tj. Preferuj DHE od DH i preferuj ECDHE od ECDH). Klucze efemeryczne zapewniają doskonałą poufność przekazywania.
- Preferuj tryby GCM lub CCM zamiast trybu CBC. Użycie uwierzytelnionego trybu szyfrowania zapobiega kilku atakom (więcej informacji można znaleźć w sekcji 3.3.2 [w SP 800-52r2]). Zauważ, że nie są one dostępne w wersjach wcześniejszych niż TLS 1.2.
- Preferuj CCM zamiast CCM_8. Ten ostatni zawiera krótszy tag uwierzytelniania, który zapewnia niższą siłę uwierzytelniania.
Ponadto, chociaż są to pliki dozwolony zestawy szyfrów, jeśli twoje TLS serwer nie obsługuje dużej liczby różnych platform i klientów, zaleca się stosowanie tylko niewielkiego podzbioru tych algorytmów. Dopuszczenie większej liczby zestawów szyfrów może poszerzyć powierzchnię ataku na serwer tylko wtedy, gdy (lub kiedy) zostanie wykryta nowa luka w protokole.
Zestawy szyfrów dla certyfikatów ECDSA | ||
---|---|---|
TLS 1.2: | ||
IANA | wartość | OpenSSL |
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 |
0xC0, 0x2B |
ECDHE-ECDSA-AES128-GCM-SHA256 |
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 |
0xC0, 0x2C |
ECDHE-ECDSA-AES256-GCM-SHA384 |
TLS_ECDHE_ECDSA_WITH_AES_128_CCM |
0xC0, 0xAC |
ECDHE-ECDSA-AES128-CCM |
TLS_ECDHE_ECDSA_WITH_AES_256_CCM |
0xC0, 0xAD |
ECDHE-ECDSA-AES256-CCM |
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 |
0xC0, 0xAE |
ECDHE-ECDSA-AES128-CCM8 |
TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 |
0xC0, 0xAF |
ECDHE-ECDSA-AES256-CCM8 |
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 |
0xC0, 0x23 |
ECDHE-ECDSA-AES128-SHA256 |
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 |
0xC0, 0x24 |
ECDHE-ECDSA-AES256-SHA384 |
TLS 1.2, 1.1 lub 1.0: | ||
IANA | wartość | OpenSSL |
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA |
0xC0, 0x09 |
ECDHE-ECDSA-AES128-SHA |
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA |
0xC0, 0x0A |
ECDHE-ECDSA-AES256-SHA |
Zestawy szyfrów dla certyfikatów RSA | ||
TLS 1.2: | ||
IANA | wartość | OpenSSL |
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 |
0xC0, 0x2F |
ECDHE-RSA-AES128-GCM-SHA256 |
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 |
0xC0, 0x30 |
ECDHE-RSA-AES256-GCM-SHA384 |
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 |
0x00, 0x9E |
DHE-RSA-AES128-GCM-SHA256 |
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 |
0x00, 0x9F |
DHE-RSA-AES256-GCM-SHA384 |
TLS_DHE_RSA_WITH_AES_128_CCM |
0xC0, 0x9E |
DHE-RSA-AES128-CCM |
TLS_DHE_RSA_WITH_AES_256_CCM |
0xC0, 0x9F |
DHE-RSA-AES256-CCM |
TLS_DHE_RSA_WITH_AES_128_CCM_8 |
0xC0, 0xA2 |
DHE-RSA-AES128-CCM8 |
TLS_DHE_RSA_WITH_AES_256_CCM_8 |
0xC0, 0xA3 |
DHE-RSA-AES256-CCM8 |
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 |
0xC0, 0x27 |
ECDHE-RSA-AES128-SHA256 |
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 |
0xC0, 0x28 |
ECDHE-RSA-AES256-SHA384 |
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 |
0x00, 0x67 |
DHE-RSA-AES128-SHA256 |
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 |
0x00, 0x6B |
DHE-RSA-AES256-SHA256 |
TLS 1.2, 1.1 lub 1.0: | ||
IANA | wartość | OpenSSL |
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA |
0xC0, 0x13 |
ECDHE-RSA-AES128-SHA |
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA |
0xC0, 0x14 |
ECDHE-RSA-AES256-SHA |
TLS_DHE_RSA_WITH_AES_128_CBC_SHA |
0x00, 0x33 |
DHE-RSA-AES128-SHA |
TLS_DHE_RSA_WITH_AES_256_CBC_SHA |
0x00, 0x39 |
DHE-RSA-AES256-SHA |
Zestawy szyfrów dla certyfikatów ECDSA | ||
TLS 1.2: | ||
IANA | wartość | OpenSSL |
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 |
0x00, 0xA2 |
DHE-DSS-AES128-GCM-SHA256 |
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 |
0x00, 0xA3 |
DHE-DSS-AES256-GCM-SHA384 |
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 |
0x00, 0x40 |
DHE-DSS-AES128-SHA256 |
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 |
0x00, 0x6A |
DHE-DSS-AES256-SHA256 |
TLS 1.2, 1.1 lub 1.0: | ||
IANA | wartość | OpenSSL |
TLS_DHE_DSS_WITH_AES_128_CBC_SHA |
0x00, 0x32 |
DHE-DSS-AES128-SHA |
TLS_DHE_DSS_WITH_AES_256_CBC_SHA |
0x00, 0x38 |
DHE-DSS-AES256-SHA |
Zestawy szyfrów dla certyfikatów DH | ||
Podpisane DSA, TLS 1.2: | ||
IANA | wartość | OpenSSL |
TLS_DH_DSS_WITH_AES_128_GCM_SHA256 |
0x00, 0xA4 |
DH-DSS-AES128-GCM-SHA256 |
TLS_DH_DSS_WITH_AES_256_GCM_SHA384 |
0x00, 0xA5 |
DH-DSS-AES256-GCM-SHA384 |
TLS_DH_DSS_WITH_AES_128_CBC_SHA256 |
0x00, 0x3E |
DH-DSS-AES128-SHA256 |
TLS_DH_DSS_WITH_AES_256_CBC_SHA256 |
0x00, 0x68 |
DH-DSS-AES256-SHA256 |
Podpisane DSA, TLS 1.2, 1.1 lub 1.0: | ||
IANA | wartość | OpenSSL |
TLS_DH_DSS_WITH_AES_128_CBC_SHA |
0x00, 0x30 |
DH-DSS-AES128-SHA |
TLS_DH_DSS_WITH_AES_256_CBC_SHA |
0x00, 0x36 |
DH-DSS-AES256-SHA |
Podpisany RSA, TLS 1.2: | ||
IANA | wartość | OpenSSL |
TLS_DH_RSA_WITH_AES_128_GCM_SHA256 |
0x00, 0xA0 |
DH-RSA-AES128-GCM-SHA256 |
TLS_DH_RSA_WITH_AES_256_GCM_SHA384 |
0x00, 0xA1 |
DH-RSA-AES256-GCM-SHA384 |
TLS_DH_RSA_WITH_AES_128_CBC_SHA256 |
0x00, 0x3F |
DH-RSA-AES128-SHA256 |
TLS_DH_RSA_WITH_AES_256_CBC_SHA256 |
0x00, 0x69 |
DH-RSA-AES256-SHA256 |
Podpisany RSA, TLS 1.2, 1.1 lub 1.0: | ||
IANA | wartość | OpenSSL |
TLS_DH_RSA_WITH_AES_128_CBC_SHA |
0x00, 0x31 |
DH-RSA-AES128-SHA |
TLS_DH_RSA_WITH_AES_256_CBC_SHA |
0x00, 0x37 |
DH-RSA-AES256-SHA |
Zestawy szyfrów dla certyfikatów ECDH | ||
Podpisane przez ECDSA, TLS 1.2: | ||
IANA | wartość | OpenSSL |
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 |
0xC0, 0x2D |
ECDH-ECDSA-AES128-GCM-SHA256 |
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 |
0xC0, 0x2E |
ECDH-ECDSA-AES256-GCM-SHA384 |
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 |
0xC0, 0x25 |
ECDH-ECDSA-AES128-SHA256 |
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 |
0xC0, 0x26 |
ECDH-ECDSA-AES256-SHA384 |
Podpisane przez ECDSA, TLS 1.2, 1.1 lub 1.0: | ||
IANA | wartość | OpenSSL |
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA |
0xC0, 0x04 |
ECDH-ECDSA-AES128-SHA |
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA |
0xC0, 0x05 |
ECDH-ECDSA-AES256-SHA |
Podpisany RSA, TLS 1.2: | ||
IANA | wartość | OpenSSL |
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 |
0xC0, 0x31 |
ECDH-RSA-AES128-GCM-SHA256 |
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 |
0xC0, 0x32 |
ECDH-RSA-AES256-GCM-SHA384 |
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 |
0xC0, 0x29 |
ECDH-RSA-AES128-SHA256 |
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 |
0xC0, 0x2A |
ECDH-RSA-AES256-SHA384 |
Podpisany RSA, TLS 1.2, 1.1 lub 1.0: | ||
IANA | wartość | OpenSSL |
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA |
0xC0, 0x0E |
ECDH-RSA-AES128-SHA |
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA |
0xC0, 0x0F |
ECDH-RSA-AES256-SHA |
TLS 1.3
TLS 1.3 ma znacznie krótszą listę zestawów szyfrów:
TLS_AES_128_GCM_SHA256 (0x13, 0x01)
TLS_AES_256_GCM_SHA384 (0x13, 0x02)
TLS_AES_128_CCM_SHA256 (0x13, 0x04)
TLS_AES_128_CCM_8_SHA256 (0x13, 0x05)
Wnioski
Mamy nadzieję, że ten krótki przewodnik pomoże Ci lepiej zrozumieć TLSi pomagają w konfiguracji TLS na własnym serwerze. W odniesieniu do standardów i zaleceń, które omówiliśmy, poniższy rozdział zawiera przykładową konfigurację, którą powinieneś móc zastosować w najpopularniejszych rozwiązaniach serwerowych. Jeśli masz jakiekolwiek pytania dotyczące tego, jak zachować zgodność online, skontaktuj się z nami, wysyłając e-mail Support@SSL.com lub klikając przycisk czatu na żywo u dołu tego ekranu.
Dodatek: przykład TLS konfiguracje
Gromadząc reguły określone w trzech dokumentach specyfikacji, nowoczesny bezpieczny serwer powinien zostać wdrożony TLS 1.2 i / lub TLS 1.3, z krótką, ale zróżnicowaną listą wybranych zestawów szyfrów. W skrócie poniżej przedstawiono przykładowe konfiguracje najpopularniejszych serwerów internetowych na rynku. Są to konfiguracje „pośrednie” (ogólnego przeznaczenia) generowane przez Mozillę Generator konfiguracji SSL: