Ръководство за TLS Съответствие със стандартите

Сигурността на транспортния слой (TLS) протоколът е основното средство за защита на мрежовите комуникации през Интернет. Тази статия е кратко ръководство, което ще ви помогне да конфигурирате защитен сървър, за да отговаря на текущите TLS стандарти.

Въведение

- Сигурност на транспортния слой (TLS) протоколът е основното средство за защита на мрежовите комуникации през Интернет. Той (и неговият предшественик, Защитен сокет слой или SSL) се използват от десетилетия в много приложения, но най-вече в браузърите, когато ги посещават HTTPS уебсайтове. TLS обикновено функционира тихо на заден план, но противно на това, което човек може да си мисли, TLS не е черна кутия, която просто работи. По-скоро сигурността TLS осигурява произтича от сътрудничеството на различни криптографски алгоритми. Освен това, TLS, както SSL преди него, непрекъснато се развива с индустрията за сигурност - новите технологични и бизнес изисквания трябва да бъдат изпълнени, докато най-новите заплахи за сигурността трябва да бъдат смекчени. Алгоритмите могат да остареят с времето или да се изоставят практиките, като всяка промяна засяга цялостната сигурност на TLS например (като този, който защитава връзката ви в момента).

Тази нестабилност мотивира различни организации за стандартизация да публикуват насочващи документи, така че да бъде минимална базова стойност за TLS сигурността може да бъде установена на определен пазар, сектор или услуга. За съжаление има много такива стандарти, като различни сектори изискват спазване на различни, приложими документи, докато самите стандарти Също еволюират във времето, приспособявайки промените в сектора, който са проектирани за защита.

Разбираемо, че се движите в това море от стандарти, за да създадете модерно TLS например може да бъде истинско главоболие за администраторите. Тази статия е кратко ръководство, което ще ви помогне да конфигурирате защитен сървър, за да отговори на очакваното TLS стандарти за 2021 г. (За допълнителна помощ също така дадохме примерни конфигурации на най-популярните решения за уеб сървъри в апендикс.)

Стандартите

Има няколко организации, които поддържат указания за TLS по отношение на мрежовата сигурност, като Министерството на здравеопазването и хуманитарните услуги на САЩ (HHS) или Националния институт за стандарти и технологии (NIST). За краткост тази статия ще проучи само трите най-приети документа:

1. - Закон за преносимост и отчетност на здравното осигуряване (HIPAA)
2. NIST на Насоки за SP 800-52r2
3. - Стандарт за сигурност на данните в индустрията на платежни карти (PCI-DSS)

HIPAA

HIPAA е регламент, приет от правителството на САЩ през 1996 г., относно сигурното управление на Защитена здравна информация (PHI). PHI се отнася до всяка цифрова информация за пациента, като резултати от тестове или диагнози. А HIPAA ръководен документ публикуван през 2013 г. гласи следното:

Валидни процеси на криптиране на данните в движение са тези, които съответстват, по целесъобразност, на NIST Special Publications 800-52, Указания за избор и използване на сигурността на транспортния слой (TLS) Реализации; 800-77, Ръководство за IPsec VPN; или 800-113, Ръководство за SSL VPN или други, които са валидирани Федерални стандарти за обработка на информация (FIPS) 140-2.

NIST стандарти

През 2005 г. NIST публикува специална публикация (SP) 800-52, описваща правилните оперативни процедури за сигурна конфигурация на a TLS например за държавни сървъри. Оттогава SP 800-52 е заменен от версии SP 800-52r1 (2014) и SP 80052r2 (2019). Тази статия следва насоките на SP 800-52r2, който в момента е стабилен.

PCI DSS

PCI-DSS е стандарт за съответствие, поддържан от Съвета за сигурност на стандартите за индустрията на разплащателни карти (PCI), който определя как се обработват данните за плащанията и картата от уеб сайтовете за електронна търговия. Относно правилната конфигурация на TLS например, PCI-DSS заявява:

„Обърнете се към индустриалните стандарти и най-добрите практики за информация относно силна криптография и защитени протоколи (напр. NIST SP 800-52 и SP 800-57, OWASP и др.)“

TLS стандарти: сглобяването им

Досега трябва да се отбележи, че всеки стандарт засяга различни системи, въз основа на тяхната функция и данните, с които обработват. Например, болничен имейл сървър може да попадне в насоките на HIPAA, тъй като обменяните съобщения могат да съдържат информация за пациента, докато CRM системата на болницата може да попадне под PCI-DSS, тъй като може да съдържа данни за кредитни карти и други клиенти. Съответствието с трите стандарта ще изисква използването на общи TLS параметри, присъстващи във всички документи.

За щастие е очевидно, че всички стандарти следват насоките на NIST за избора на TLS параметри. Това означава, че в момента на настоящото писане, съвместимостта с SP 800-52r2 трябва да направи и сървър, съвместим с HIPAA и PCI-DSS. (Добре, това не е така точно вярно, но нещата ще станат по-ясни в следващия раздел.)

конфигуриране TLS параметри

Нивото на сигурност, че TLS осигурява е най-засегнат от версия на протокол (т.е. 1.0, 1.1 и т.н.) и позволеното шифрови апартаменти, Шифрите са алгоритми, които извършват криптиране и декриптиране. Въпреки това, a шифров пакет е набор от алгоритми, включително шифър, алгоритъм за обмен на ключове и хеширащ алгоритъм, които се използват заедно за създаване на сигурна TLS Връзка. най-много TLS клиентите и сървърите поддържат множество алтернативи, така че те трябва да преговарят при установяване на защитена връзка, за да изберат обща TLS версия и шифров пакет.

TLS версия на протокол

Относно TLS поддръжка на версия, NIST SP 800-52r2 заявява следното:

Сървъри, които поддържат само държавни приложения ще да бъде конфигуриран да се използва TLS 1.2 и трябва да бъде конфигуриран да се използва TLS 1.3 също. Тези сървъри не трябва да бъде конфигуриран да се използва TLS 1.1 и не ще употреба TLS 1.0, SSL 3.0 или SSL 2.0.

...

Сървъри, които поддържат приложения за граждани или бизнес (т.е. клиентът може да не е част от държавна ИТ система) ще да бъде конфигуриран да преговаря TLS 1.2 и трябва да бъде конфигуриран да преговаря TLS 1.3. Използването на TLS версии 1.1 и 1.0 обикновено не се препоръчват, но тези версии могат да бъдат конфигурирани, когато е необходимо, за да се даде възможност за взаимодействие с гражданите и бизнеса ... Тези сървъри не ще позволяват използването на SSL 2.0 или SSL 3.0.

агенции ще подкрепа TLS 1.3 до 1 януари 2024 г. След тази дата сървъри ще подкрепа TLS 1.3 както за правителствени, така и за граждански или бизнес приложения. Като цяло сървъри, които поддържат TLS 1.3 трябва да бъде конфигуриран да се използва TLS 1.2 също. Въпреки това, TLS 1.2 може да бъде деактивиран на сървъри, които поддържат TLS 1.3 ако е установено, че TLS 1.2 не е необходим за оперативна съвместимост.

Докато TLS 1.0 е забранено и TLS 1.1 е оттеглено за правителствените сайтове, в указанията на NIST се посочва, че за съвместимост с услуги на трети страни, управлявани от правителството сървъри може прилагане на TLS 1.0 и 1.1, когато е необходимо. Съгласно PCI-DSS 3.2.1 (текущата версия), съвместими сървъри трябва да откажат подкрепа за TLS 1.0 и „мигрират до минимум TLS 1.1, за предпочитане TLS 1.2. “ HIPAA технически позволява използването на всички версии на TLS. По този начин минималният често поддържан TLS версията е 1.1; обаче PCI-DSS и NIST настоятелно препоръчват използването на по-сигурните TLS 1.2 (и, както се вижда по - горе, NIST препоръчва приемането на TLS 1.3 и планира да се нуждае от подкрепа до 2024 г.).

Cipher Suites

TLS 1.2 и по-рано

SP 800-52r2 определя разнообразие от приемливи шифрови апартаменти за TLS 1.2 и по-стари. Стандартът не изисква поддръжка за конкретни апартаменти за шифри, но предлага насоки за избора на по-силни:

1. Предпочитайте ефемерни ключове пред статични ключове (т.е. предпочитайте DHE пред DH и предпочитайте ECDHE пред ECDH). Ефемерните ключове осигуряват перфектна тайна напред.
2. Предпочитайте режимите GCM или CCM пред режима CBC. Използването на удостоверен режим на криптиране предотвратява няколко атаки (вижте раздел 3.3.2 [от SP 800-52r2] за повече информация). Имайте предвид, че те не са налични във версии преди TLS 1.2.
3. Предпочитайте CCM пред CCM_8. Последният съдържа по-кратък етикет за удостоверяване, който осигурява по-ниска сила на удостоверяване.

Освен това, въпреки че това са позволен шифрови апартаменти, ако вашите TLS сървърът не се занимава с голямо разнообразие от различни платформи и клиенти, препоръчително е да се използва само малък подмножество от тези алгоритми. Разрешаването на повече пакети от шифри може да разшири атакуващата повърхност само на вашия сървър, ако (или когато) бъде открита нова уязвимост на протокола.

TLS 1.3

TLS 1.3 има много по-кратък списък с шифрени апартаменти:

• 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)

Заключение

Надяваме се, че това кратко ръководство ще ви помогне да разберете повече за TLSи да ви помогне при конфигуриране TLS на вашия собствен сървър. По отношение на стандартите и препоръките, които обсъдихме, следващият раздел съдържа примерна конфигурация, която трябва да можете да приложите към най-популярните решения за уеб сървъри. Ако имате някакви въпроси за това как да поддържате онлайн съответствие, не се колебайте да се свържете с нас по имейл Support@SSL.com или щракнете върху бутона за чат на живо в долната част на този екран.

Приложение: Пример TLS конфигурации

Събирайки правилата, посочени в трите спецификационни документа, трябва да се приложи модерен защитен сървър TLS 1.2 и / или TLS 1.3, с кратък, но разнообразен списък от избрани апартаменти за шифроване. Като кратка справка, примерни конфигурации за най-популярните уеб сървъри на пазара са показани по-долу. Това са „междинни“ (с общо предназначение) конфигурации, генерирани с Mozilla Генератор на SSL конфигурация:

... SSL Протокол всички -SSLv3 -TLSv1 -TLSv1.1 SSLCipher Suite ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES128-GCM-SHA256: ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-RSA-AES256-GCM-SHA-ECM POLY384: ECDHE-RSA-CHACHA20-POLY1305: DHE-RSA-AES20-GCM-SHA1305: DHE-RSA-AES128-GCM-SHA256 SSLHonorCipher Поръчка изключена SSL Сесия Билети изключени

... ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;

... ssl.openssl.ssl-conf-cmd = ("Протокол" => "ВСИЧКИ, -SSLv2, -SSLv3, -TLSv1, -TLSv1.1 ") ssl.cipher-list =" ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES128-GCM-SHA256: ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-RSA-AES256-GCM SHA384: ECDHE-ECDSA-CHACHA20-POLY1305: ECDHE-RSA-CHACHA20-POLY1305: DHE-RSA-AES128-GCM-SHA256: DHE-RSA-AES256-GCM-SHA384 "ssl.honor-шифър-поръчка ="

...

ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 ssl-default-bind-options prefer-client-ciphers no-sslv3 no-tlsv10 не-tlsv11 не-tls-tickets

ssl-default-server-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
ssl-default-server-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 ssl-default-server-options no-sslv3 no-tlsv10 не-tlsv11 не-tls-билети

... Политики: - PolicyName: Mozilla-intermediate-v5-0 PolicyType: SSLNegotiationPolicyType Атрибути: - Name: Protocol-TLSv1.2 Стойност: вярно - Име: Дефинирана от сървъра стойност за поръчка на шифър: невярно - Име: ECDHE-ECDSA-AES128-GCM-SHA256 Стойност: вярно - Име: ECDHE-RSA-AES128-GCM-SHA256 Стойност: вярно - Име: ECDHE-ECDSA-AES256-GCM-SHA384 Стойност: вярно - Име: ECDHE-RSA-AES256-GCM-SHA384 Стойност: вярно - Име: DHE-RSA-AES128-GCM-SHA256 Стойност: вярно - Име: DHE-RSA -AES256-GCM-SHA384 Стойност: вярно