Введение
Безопасность транспортного уровня (TLS) - это широко используемый протокол шифрования, который позволяет сторонам безопасно общаться через Интернет. Используя сертификаты и инфраструктуру открытых ключей (PKI), стороны могут идентифицировать друг друга через доверенного посредника и устанавливать зашифрованные туннели для безопасной передачи информации.Использование рекомендаций по настройке TLS, изложенных в этом документе, поможет улучшить шифрование и аутентификацию для обмена данными через Интернет и по электронной почте.
Шифрование веб-трафика
TLS и защищенный протокол передачи гипертекста (HTTPS) - это протоколы, которые обеспечивают шифрование и аутентификацию, чтобы убедить людей (в данном случае именуемых пользователями), что они подключаются к веб-сайтам, которые они намереваются посещать, и что их взаимодействия не могут быть просмотрены или изменены. Эти протоколы поддерживаются криптографическими документами, известными как сертификаты, которые могут подтверждать подлинность веб-сайтов.Все общедоступные веб-сайты и интерфейсы прикладного программирования (API) с поддержкой протокола передачи гипертекста (HTTP) должны использовать HTTPS для защиты конфиденциальности и целостности взаимодействия веб-сайтов.
Шифрование почтового трафика
Оппортунистический TLS можно использовать с протоколом простой передачи почты (SMTP) для защиты конфиденциальности и целостности электронной почты. Используя TLS и сертификаты, почтовые серверы могут аутентифицировать друг друга и устанавливать зашифрованную связь перед передачей электронной почты.Все почтовые серверы должны предлагать и использовать TLS для защиты конфиденциальности и целостности сообщений электронной почты, когда это возможно.
Инфраструктура открытых ключей
Механизмы PKI являются ключевым компонентом процесса проверки подлинности веб-сайтов и почтовых серверов. Это достигается доверенными центрами сертификации (CA), которые подтверждают идентичность серверов и подтверждают, что открытый ключ, содержащийся в сертификате, принадлежит объекту, указанному в сертификате.Как работают сертификаты, TLS, HTTPS и альтернативный TLS
Сертификаты
Многие интернет-протоколы используют сертификаты X.509 [1], позволяющие веб-браузерам и системам аутентифицировать веб-сайты и серверы с помощью криптографии с открытым ключом [2]. Например, когда пользователь пытается получить доступ к веб-сайту с поддержкой HTTPS, веб-сервер отправляет веб-браузеру пользователя свой открытый ключ, содержащийся в сертификате, и демонстрирует, что у него есть соответствующий закрытый ключ. Затем веб-браузер проверяет, был ли сертификат выдан доверенным центром сертификации, действителен и был выпущен для домена веб-сайта, к которому пользователь обращается.Чтобы получить сертификат, владелец сервера должен будет обратиться в ЦС и продемонстрировать, что у него есть контроль над доменом, для которого он запрашивает сертификат.
Центры сертификации в веб-браузерах
Распространенные веб-браузеры (например, Google Chrome, Firefox, Microsoft Edge и Safari) поддерживают собственный список доверенных центров сертификации. Если пользователь посещает веб-сайт, который предлагает сертификат, подписанный доверенным центром сертификации, веб-браузер примет сертификат без отображения ошибки доверия. Однако, если пользователь посещает веб-сайт, предлагающий сертификат, не подписанный доверенным центром сертификации, веб-браузер отобразит сообщение об ошибке и откажется устанавливать зашифрованное соединение, пока пользователь не признает риск.На практике доверенные центры сертификации распространенных веб-браузеров тесно связаны. Кроме того, когда один разработчик веб-браузера решает удалить доверенный центр сертификации, он часто координирует свои действия с другими разработчиками веб-браузера, или другие разработчики веб-браузера вскоре последуют его примеру.
Если центр сертификации, подписавший сертификат веб-сайта, удаляется из списка доверенных центров сертификации веб-браузеров, пользователи веб-сайта начнут получать сообщения об ошибках безопасности при попытке подключения к веб-сайту. Это может вызвать некоторые сбои и затруднения для организации, владеющей веб-сайтом, до тех пор, пока сертификат не будет заменен.
При выборе ЦС для выдачи сертификата для веб-сайта или API с поддержкой HTTP организациям следует учитывать репутацию и историю ЦС, а также других организаций, которые поддерживают или используют ЦС. Наконец, цена сертификатов не является показателем надежности, качества или долговечности.
Центры сертификации на почтовых серверах
Почтовые серверы поддерживают TLS с помощью механизма, известного как оппортунистический TLS. В условиях гибкого TLS любое шифрование считается лучше, чем отсутствие шифрования. Следовательно, почтовые серверы исторически принимали сертификаты с истекшим сроком действия, не подписанные доверенным центром сертификации или не совпадающие с именем получающего почтового сервера. Однако новые стандарты и улучшенная гигиена серверов начинают ставить под вопрос эти методы.Поскольку проверка сертификатов исторически не была критичной для потока электронной почты, почтовые серверы могли не поддерживать свой внутренний список доверенных центров сертификации в актуальном состоянии и не согласовывать со списками известных и надежных общедоступных центров сертификации. Следовательно, операторы почтовых серверов могут обнаружить, что им необходимо реализовать процессы, обеспечивающие поддержание списка приемлемых центров сертификации на их почтовых серверах.
При отсутствии собственной конкретной политики операторы почтовых серверов могут выбрать один из хорошо известных веб-браузеров и следовать списку утвержденных центров сертификации в веб-браузере в качестве доверенных корневых центров сертификации.
Типы сертификатов
Центры сертификации обычно предлагают три продукта: сертификаты проверки домена (DV), сертификаты проверки организации (OV) и сертификаты расширенной проверки (EV):- Сертификаты DV могут быть выданы любому, кто демонстрирует контроль над доменом.
- Сертификаты OV содержат более подробную информацию об организации, которой они выдаются.
- Сертификаты EV считаются более надежными, чем сертификаты OV и DV, поскольку они требуют от организации предоставления обширной документации для подтверждения личности и владения доменом. Получение сертификатов EV требует больше времени и ресурсов по сравнению с сертификатами DV. Выдачу этих сертификатов нельзя автоматизировать.
Сертификаты OV имеют цену выше сертификатов DV и позволяют добавлять в сертификат больше организационных данных. Пользователи не узнают разницу между сертификатом DV и OV без тщательного изучения деталей сертификата.
Сертификаты EV являются самыми дорогими и требуют дополнительных проверок личности, прежде чем их можно будет выдать. Распространенные веб-браузеры, такие как Google Chrome, Firefox и Safari, использовались для предоставления пользователям дополнительных визуальных подсказок при использовании сертификата EV, но этого больше не происходит [3].
Три типа сертификатов различаются по уровню уверенности в том, что домен принадлежит организации, а не по уровню предлагаемого шифрования. Более дорогой сертификат не обеспечивает большего уровня конфиденциальности.
Алгоритмы шифрования
Алгоритмы шифрования сертификатов и хеширования следует выбирать из Руководства по информационной безопасности правительства Австралии (ISM). Их можно указать в ЦС при запросе сертификата. Чтобы изменить используемые алгоритмы, необходимо будет выпустить новый сертификат.Безопасность транспортного уровня
TLS - это криптографический протокол, который позволяет осуществлять сквозную зашифрованную связь по сети. Он используется во множестве приложений и основан на устаревшем протоколе Secure Socket Layer (SSL), разработанном Netscape в 1994 году.Версии TLS до TLS 1.3 могут быть уязвимы для криптографического взлома. Если организациям необходимо использовать более старые версии TLS, следует позаботиться о выборе комплектов шифров и настройке функций протокола в соответствии с этим руководством и ISM. SSL не должен использоваться.
Наборы шифров
Ключевым элементом понимания того, как работает TLS, является понимание того, что такое набор шифров. Набор шифров - это набор алгоритмов, которые помогают защитить соединение TLS. Наборы шифров обычно включают три разных алгоритма:- алгоритм создания ключа для безопасного установления симметричного ключа между двумя устройствами
- алгоритм массового шифрования (который использует симметричный ключ) для шифрования трафика, отправляемого через соединение
- алгоритм кода аутентификации сообщения для обеспечения уверенности в том, что трафик не изменяется при передаче.
TLS 1.3 удалил уязвимые наборы шифров, обнаруженные в TLS 1.2, но представил более надежные наборы шифров. Рекомендации по приемлемым комплектам шифров приведены в Приложении А.
Процесс установления связи TLS
Ниже приводится упрощенное объяснение процесса подтверждения TLS:- клиент и сервер согласовывают криптографический протокол (например, TLS 1.3) и набор шифров
- клиент аутентифицирует сервер:
- сервер предлагает свой сертификат и доказывает, что он содержит закрытый ключ, подписывая сообщение, которое клиент может проверить, используя открытый ключ, содержащийся в сертификате
- клиент проверяет идентичность сервера, проверяя, что имя сервера совпадает с именем в сертификате
- клиент подтверждает, что сертификат действителен, поскольку он актуален, не отозван и не выпущен центром сертификации, которому клиент доверяет
- сервер и клиент обмениваются симметричным ключом.
Совершенная прямая секретность
Perfect Forward Secrecy (PFS) - это функция некоторых наборов шифров, которая снижает риск, связанный с взломанными сеансовыми ключами. С PFS отдельные сеансы имеют уникальные сеансовые ключи. В результате скомпрометированный сеансовый ключ не может использоваться для расшифровки других сеансов. Это означает, что атаки, основанные на длительном хранении зашифрованных данных, становятся невозможными. Организации должны использовать только комплекты шифров, поддерживающие PFS.Безопасное повторное согласование и повторное согласование по инициативе клиента
TLS 1.3 не использует повторное согласование, однако, если используется TLS 1.2 или более ранняя версия, при определенных обстоятельствах может потребоваться повторное согласование. Например, когда сеанс истек, но стороны хотят отправить больше данных, одноранговый узел хочет изменить комплекты шифров или сторонам необходимо выполнить аутентификацию. К сожалению, повторное согласование уязвимо для атак типа "человек посередине" [6]. Для TLS 1.2 или более ранней версии следует включить безопасное повторное согласование, чтобы снизить уязвимость к атакам типа "человек в середине".Инициированное клиентом повторное согласование, безопасное или иное, влияет на производительность веб-серверов. Злоумышленник может отправить множество запросов на повторное согласование, чтобы потреблять ресурсы сервера, вызывая отказ в обслуживании [7]. Для TLS 1.2 или более ранней версии необходимо отключить инициируемое клиентом повторное согласование, чтобы предотвратить атаки типа «отказ в обслуживании». Для получения дополнительной информации по этому вопросу см Макафите Советы по организации защиты SSL перезаключения советов [8].
Сжатие TLS
Сжатие TLS использовалось для уменьшения пропускной способности связи TLS. Однако было обнаружено, что сжатие TLS приводит к непреднамеренной утечке информации, о чем свидетельствует эксплойт CRIME [9]. Сжатие TLS следует отключить.Регулярно проверяйте настройки TLS
Оптимальные настройки TLS и комплекты шифров изменяются по мере выпуска новых стандартов, увеличения вычислительной мощности и обнаружения уязвимостей в системе безопасности. Организации должны пересматривать свои конфигурации TLS и шифров ежегодно или всякий раз, когда публично раскрываются основные уязвимости безопасности, чтобы гарантировать, что защита остается эффективной и соответствует ожиданиям их клиентов.Безопасный протокол передачи гипертекста
HTTPS обеспечивает безопасную связь через ненадежную сеть, уменьшая возможность злоумышленников отслеживать действия пользователя. Важно отметить, что отсутствие HTTPS может подорвать доверие к веб-сайту, поскольку обычные веб-браузеры будут предупреждать пользователей при посещении таких веб-сайтов [10] , а также при попытке ввести какую-либо информацию на таких веб-сайтах [11]. Также следует отметить, что некоторые веб-браузеры будут блокировать контент, который доставляется через HTTP, при подключении к веб-сайту через HTTPS [12].Весь контент веб-сайта должен доставляться с использованием HTTPS, и любые попытки доступа к ресурсам с использованием HTTP должны автоматически перенаправляться на тот же ресурс по HTTPS. Кроме того, приложения, использующие API с поддержкой HTTP, также должны использовать TLS для защиты конфиденциальности и целостности передаваемой информации.
Существует множество мифов о причинах отказа от HTTPS. Они опровергнуты в статье « Нужен ли моему сайту HTTPS» [13].
Строгая безопасность транспорта HTTP
HTTP Strict Transport Security (HSTS) - это механизм политики веб-безопасности, который помогает защитить пользователей. Это достигается за счет того, что веб-серверы могут сообщать веб-браузерам, что они должны взаимодействовать с веб-сервером только через HTTPS. Таким образом, веб-браузеры будут динамически адаптировать любые HTTP-запросы к HTTPS-запросам. HSTS также помогает защитить от подслушивания, атак типа "человек посередине" и активных сетевых атак. Организации должны использовать HSTS для защиты конфиденциальности пользователей.Оппортунистический TLS и электронная почта
Оппортунистический TLS позволяет почтовым серверам использовать шифрование для защиты передаваемой электронной почты, когда отправляющий и получающий почтовые серверы поддерживают TLS.Перед передачей данных отправляющий почтовый сервер (если он поддерживает TLS) спросит получающий почтовый сервер, поддерживает ли он TLS. Если получающий почтовый сервер указывает, что это так, то два почтовых сервера начнут попытки согласовать версию протокола TLS и приемлемый набор шифров. Однако, если получающий почтовый сервер указывает, что он не поддерживает TLS, отправляющий почтовый сервер продолжит передачу электронной почты в виде обычного текста.
Необходимость поддерживать передачу обычного текста на почтовые серверы, не поддерживающие TLS, делает оппортунистический TLS очень восприимчивым к атакам с понижением уровня (также известным как TLS-удаление) со стороны посредника [14].
Строгая транспортная безопасность агента пересылки почты и создание отчетов SMTP TLS
Подобно HSTS, строгая транспортная безопасность агента пересылки почты (MTA-STS) предоставляет владельцу домена механизм, позволяющий указать, что их почтовые серверы поддерживают шифрование TLS и что электронная почта не должна отправляться на эти почтовые серверы, если не будет установлено удовлетворительное шифрование.Отправляющий почтовый сервер с поддержкой MTA-STS, который пытается отправить электронное письмо в домен, опубликовавший политику MTA-STS в принудительном режиме, отправит электронное письмо только в том случае, если:
- он может согласовывать как минимум соединение TLS 1.2 с почтовым сервером получателя
- почтовый сервер получателя представляет сертификат для аутентификации, который:
- подписан ЦС, которому доверяет отправляющий почтовый сервер
- согласуется с именем почтового сервера получателя, опубликованным в записи MX домена и политике MTA-STS
- в противном случае действительна (например, не истекла или не отозвана).
- даунгрейд для выполнения атак с использованием обычного текста
- переход на более раннюю версию для выполнения атак с более низкой версией протокола
- атаки на поддельные, ненадежные, самоподписанные или иным образом недействительные сертификаты (когда посредник завершает сеанс TLS в своей системе, полагаясь на слабую проверку сертификата в оппортунистическом TLS).
MTA-STS определен в RFC 8461 Internet Engineering Task Force (IETF) и поддерживается TLS-RPT, как определено в IETF RFC 8460.
Политики MTA-STS доступны путем публикации двух частей информации:
- запись TXT в DNS, которая указывает, что домен имеет политику MTA-STS и текущий номер версии ( _mta-sts. <example domain> )
- политика MTA-STS (простой текстовый файл) в стандартном местоположении веб-сайта для домена ( ).
- v это версия
- id - это идентификатор записи, которую отслеживают почтовые серверы с поддержкой MTA-STS, чтобы определить, нужно ли им запрашивать файл политики, который обычно проверяется только при изменении идентификационного номера в DNS.
- версия: STSv1
- режим: тестирование
- mx: * .example1.org.au
- max_age: 600
- версия - это версия MTA-STS (в настоящее время поддерживается только версия 1)
- режим - это текущий подход к требованию TLS для подключений электронной почты, сначала следует использовать тестирование, а затем усилить строгость, чтобы обеспечить соблюдение, когда вы станете более уверенными
- mx - это почтовый сервер, к которому применяется эта политика
- max_age - минимальное время в секундах, в течение которого эта политика должна кэшироваться.
- принятие решения о получении отчетов по электронной почте или HTTPS и создание места для получения этих отчетов (например, адреса электронной почты)
- публикация записи TXT в DNS для вашего домена ( _smtp._tls. <ваш домен> ), которая указывает точку отчетности для отчетов TLS.
Пример политики TLS-RPT: v = TLSRPTv1; rua = mailto: [email protected], где:
- v это версия
- rua - это адрес для отчетов TLS-RPT, указывающий, что отчеты следует отправлять по электронной почте.
Риски от МТА-СТС
Внедрение MTA-STS в принудительном режиме является указанием владельца домена на то, что конфиденциальность и целостность потоков электронной почты более важны, чем доступность. Следовательно, владелец домена соглашается с тем, что потоки электронной почты могут быть прерваны, а не электронная почта, которая потенциально может быть перехвачена, раскрыта или изменена третьими сторонами.Организации, желающие внедрить MTA-STS, должны:
- обеспечить адекватный мониторинг потоков электронной почты и наличие TLS-RPT
- примите тот факт, что даже при хорошем мониторинге MTA-STS может иногда нарушать потоки электронной почты.
Как реализовать сертификаты, TLS и HTTPS
Какие наборы шифров и методы шифрования поддерживать
Выбор надежных комплектов шифров важен для конфиденциальности пользователей. Для алгоритма подписи сертификата организациям рекомендуется использовать алгоритм цифровой подписи с эллиптической кривой (ECDSA) (256 бит или больше) или Rivest-Shamir-Adleman (RSA) (2048 бит или больше). При использовании криптографии с эллиптической кривой следует использовать кривую из Федерального стандарта обработки информации 186-4.Организации не должны использовать какой-либо набор шифров, который использует следующие алгоритмы, поскольку у них есть криптографические слабые места:
- Ривест шифр 2
- Ривест шифр 4
- Сообщение-Дайджест 5
- Стандарт шифрования данных
- ЭКСПОРТ
- ЗНАЧЕНИЕ NULL
- Алгоритм безопасного хеширования 1
- Анонимный Диффи-Хеллман
- Анонимная эллиптическая кривая Диффи-Хеллмана.
Выберите и установите сертификат
Как упоминалось ранее, три типа сертификатов обеспечивают одинаковый уровень безопасности, отличающийся только уровнем гарантии того, что домен принадлежит организации. Если нет бизнес-требований к сертификату более высокого уровня надежности, следует использовать бесплатный сертификат DV. Кроме того, использование CA, который обеспечивает поддержку протокола Автоматизированной среды управления сертификатами (ACME) [15] , позволит поддерживать HTTPS без особых затрат на обслуживание.Let's Encrypt [16] - это пример бесплатного поставщика сертификатов DV, который поддерживает ACME. Пример настройки Let's Encrypt с автоматическим обновлением сертификатов приведен в конце этого документа. Для получения дополнительной информации о Let's Encrypt см. Их руководство по началу работы [17].
Автоматическое продление сертификата
Организации должны стремиться автоматизировать обновление сертификатов. Это можно сделать с помощью центра сертификации, поддерживающего протокол ACME. Автоматизация обновления сертификата сводит к минимуму риск того, что веб-сайт станет небезопасным или даже недоступным, если его сертификат не будет обновлен вовремя [18].Certbot [19] - это обычный клиент ACME, который помогает в получении и установке сертификатов Let's Encrypt. Он прост, имеет исчерпывающую документацию и работает на многих платформах. Certbot может настраивать перенаправления HTTP, HSTS и загружать все ресурсы через HTTPS. В качестве альтернативы список альтернативных клиентов ACME доступен на веб-сайте Let's Encrypt [20].
Ручная настройка
Если вы выбрали установку сертификата вручную, необходимо будет создать запрос на подпись сертификата (CSR), заказать соответствующий сертификат, а затем установить сертификат.Есть несколько ресурсов, которые могут помочь в этом процессе, такие как текстовое руководство wikiHow [21] и видеоуроки GlobalSign:
- создание CSR с помощью Microsoft Management Console [22]
- создание CSR в Microsoft IIS 10 [23]
- создание хранилища ключей Java и создание CSR [24]
- создание CSR в Apache OpenSSL [25]
- установка сертификата TLS на Microsoft IIS [26]
- установка сертификата TLS на сервере Apache Tomcat [27]
- установка сертификата TLS на сервере NGINX [28] .
После завершения ручной настройки тестер TLS, такой как SSL Labs [31], может проверить реализацию.
Перенаправить HTTP-запросы
Чтобы гарантировать, что пользователи, пытающиеся получить доступ к веб-сайту через HTTP, будут перенаправлены на HTTPS, необходимо отредактировать конфигурацию веб-сервера или обратного прокси. Хотя синтаксис будет отличаться в зависимости от программного обеспечения веб-сервера, ниже показан пример HTTP-сервера Apache, который вызывает перенаправление HTTP 301 всякий раз, когда запрашивается HTTP-версия веб-сайта.- RewriteEngine On
- Скидка RewriteCond% {HTTPS}
- RewriteRule ^ (. *) $ Https: //% {HTTP_HOST}% {REQUEST_URI} [L, R = 301]
В качестве альтернативы перенаправление может быть достигнуто в IIS с помощью модуля перезаписи унифицированного указателя ресурсов (URL) [32], в то время как Let's Encrypt и Certbot могут настраивать перенаправления автоматически при получении сертификата.
Независимо от того, как реализовано перенаправление HTTP на HTTPS, веб-сайты должны перенаправлять на версию HTTPS веб-сайта перед перенаправлением в другое место. Например, при перенаправлении запросов на website.com.au на www.website.com.au обязательно сначала перенаправьте на HTTPS-версию website.com.au перед перенаправлением на www.website.com.au. Это необходимо для правильной работы HSTS. После того, как конфигурация перенаправления будет протестирована и подтверждена, лучше всего использовать 301 (постоянное) перенаправление, поскольку это обычно улучшает рейтинг в поисковых системах.
Проверить на смешанный контент
Хотя пользователи могут получить доступ к веб-сайту через HTTPS, некоторые части веб-сайта могут быть получены с помощью HTTP, например изображения или встроенный контент. Большинство веб-браузеров блокируют этот смешанный контент. Чтобы проверить, есть ли на веб-сайте проблемы со смешанным содержимым, либо используйте веб-консоль Firefox для просмотра отдельных страниц [33], либо воспользуйтесь бесплатными онлайн-сервисами, такими как Missing Padlock - SSL Checker [34].Улучшение поисковой оптимизации
Перемещение веб-сайта на HTTPS приведет к тому, что поисковые системы будут рассматривать его как новый, что может снизить его рейтинг в поисковых системах. Однако переход на HTTPS также может улучшить рейтинг в поисковых системах, поскольку многие поисковые системы помещают сайты, загруженные по HTTPS, выше в своих результатах поиска [35]. Чтобы свести к минимуму любое негативное влияние на оптимизацию поисковых систем веб-сайтов, новые веб-сайты HTTPS могут быть добавлены и проверены, например, в консоли поиска Google [36]. Это повторно просканирует веб-сайт и отправит новую карту сайта XML для версии HTTPS [37].Заголовок HSTS
Даже если конфигурации HTTPS и перенаправления HTTP настроены правильно, заголовок HSTS все равно должен использоваться. Это гарантирует, что в течение определенного периода времени пользователи смогут подключаться к веб-сайту только с использованием HTTPS. Это рекомендуется для предотвращения перехвата злоумышленниками первоначальных HTTP-запросов пользователей. При использовании Let's Encrypt и Certbot отправка заголовков HSTS может быть настроена автоматически при получении сертификата.Дополнительную информацию о реализации HSTS можно получить в GlobalSign [38].
Подпишитесь на список предварительной загрузки HSTS
Подписка на список предварительной загрузки HSTS [39] гарантирует, что веб-браузер пользователя предотвратит отправку HTTP-запросов на указанные веб-сайты. Это отличается от заголовка HSTS, поскольку он возникает до того, как пользователь впервые посетил веб-сайт, при условии, что он использует веб-браузер, который поддерживает список предварительной загрузки. Таким образом, пользователи защищены от атак, когда злоумышленник предотвращает отправку заголовка HSTS, например, при атаках типа "человек в середине".Следуйте советам на https://hstspreload.org/ , чтобы зарегистрировать веб-сайты в списке предварительной загрузки HSTS.
Немедленно прекратите поддержку TLS 1.0 и TLS 1.1
Все версии TLS до TLS 1.2, включая SSL, считаются небезопасными из-за недостатка в самом протоколе или использования уязвимых наборов шифров, которые могут привести к утечке конфиденциальной информации. Таким образом, начиная с 2020 года поддержка версий TLS до TLS 1.2 будет прекращена Google [40] , Mozilla [41] , Microsoft [42] и Apple [43]. Важно отметить, что будет продолжена поддержка TLS 1.0 или TLS 1.1. требуется по любой причине, организациям настоятельно рекомендуется связаться с центром кибербезопасности, чтобы обсудить возможные стратегии снижения рисков.Помните об ограничениях TLS 1.2
Для HTTP версии 2 (HTTP / 2) требуется TLS 1.2 или выше, который обеспечивает значительное улучшение производительности по сравнению с HTTP и должен поддерживаться для обеспечения лучшего взаимодействия с пользователем. Однако из-за недостатков TLS 1.2 и некоторых из включенных наборов шифров использование HTTP / 2 с TLS 1.2 ограничено. Например, HTTPS может дать сбой, если незащищенное повторное согласование и сжатие не были отключены для TLS 1.2 в настройках веб-сервера. Дополнительные советы по ограничениям, связанным с использованием TLS 1.2, можно найти в стандарте HTTP / 2 [44].Начните переход с TLS 1.2 на TLS 1.3
Как отмечалось ранее, TLS 1.3 обеспечивает множество преимуществ в плане безопасности и производительности по сравнению с TLS 1.2 и более ранними версиями. Простой способ отключить старые версии TLS - обновить конфигурации веб-сервера (например, в качестве примера конфигурации для HTTP-сервера Apache можно включить SSLProtocol TLSv1.3 в файл конфигурации). В некоторых случаях программное обеспечение веб-сервера необходимо обновить до последней версии для поддержки TLS 1.3. Кроме того, при использовании сети распространения контента (CDN) для включения TLS 1.3 для внешних клиентов может потребоваться только установка флажка в настройках конфигурации. Конфигурация шифрования между любыми исходными серверами и CDN также может потребовать корректировки.Однако важно отметить, что, поскольку TLS не имеет обратной совместимости, отказ от поддержки TLS 1.2 приведет к тому, что устаревшие веб-браузеры не смогут получить доступ к веб-сайтам с использованием TLS 1.3. В таких случаях рекомендуется поощрять пользователей обновлять свой веб-браузер до последней версии, чтобы получить поддержку TLS 1.3 и защитить свою конфиденциальность. Однако, если переход с TLS 1.2 на TLS 1.3 невозможен в краткосрочной перспективе, риски для пользователей можно снизить за счет:
- удаление поддержки сжатия
- отключение инициированного клиентом повторного согласования
- отключение повторного согласования, если версия TLS не поддерживает безопасное повторное согласование
- только включение безопасных шифров.
Вики Mozilla предоставляет советы по настройке TLS, включая примеры конфигураций для безопасности, совместимости и устаревших систем [45]. Он также указывает, с какими веб-браузерами будет совместима конкретная конфигурация.
Дополнительные ресурсы
Дополнительные ресурсы по реализации TLS доступны из следующих источников:- В SSL Labs есть советы по передовым методам развертывания TLS [46]
- Инженерная группа Интернета опубликовала Рекомендации по безопасному использованию TLS [47]
- Инструмент Google Lighthouse [48] может помочь в обнаружении содержимого только по протоколу HTTP, а также предоставляет общие советы по безопасности веб-сайтов.
- Mozilla имеет генератор конфигурации TLS для различного программного обеспечения веб-сервера [49]
- Mozilla Observatory предоставляет для веб-сайтов оценочную карточку HTTP и TLS [50].
Пример использования Let's Encrypt и Certbot
В этом тематическом исследовании показано, как включить HTTPS с помощью Let's Encrypt и Certbot в Ubuntu 16.04 с HTTP-сервером Apache. Он использует упрощенный сценарий развертывания, в котором веб-сервер выполняет собственное завершение TLS и генерирует собственные запросы на обновление сертификатов. В зависимости от контекста безопасности организации могут использовать прокси-серверы и другую инфраструктуру безопасности как часть своего решения.Во-первых, добавьте необходимые репозитории программного обеспечения и установите Certbot, выполнив следующие команды:
- sudo apt update
- sudo apt установить общие свойства программного обеспечения
- sudo add-apt-репозиторий вселенная
- sudo add-apt-репозиторий ppa: certbot / certbot
- sudo apt update
- sudo apt install certbot python-certbot-apache.
- --rsa-key-size 2048 устанавливает длину ключа RSA в битах равной 2048
- --redirect автоматически перенаправляет веб-сайт на версию HTTPS.
- --hsts гарантирует автоматическую отправку заголовка HSTS.
После выполнения указанной выше команды создания сертификата Certbot запросит адрес электронной почты для уведомлений о продлении и безопасности. Введите предпочтительный адрес электронной почты и нажмите Enter. Затем он попросит принять их Условия использования. После просмотра введите «A» и нажмите Enter. Затем он предложит отправить электронное письмо от Electronic Frontier Foundation. Нажмите «Y» или «N» и нажмите Enter. Наконец, Certbot запросит домен веб-сайта. Введите его и нажмите Enter.
Поскольку сертификаты действительны только 90 дней, их нужно будет часто обновлять. К счастью, пакеты Certbot поставляются с заданием Cron, которое автоматически обновляет сертификаты до истечения срока их действия. Чтобы проверить, что все работает правильно, выполните следующую команду: sudo certbot Renew --dry-run. Обратите внимание, что дополнительные флаги, используемые при создании сертификата, не должны указываться, так как «обновить» будут использовать настройки последнего успешно созданного / обновленного сертификата.
Как зашифровать электронную почту с помощью гибкого TLS
Реализация гибкого TLS для защиты потоков электронной почты имеет много общего с внедрением HTTPS для защиты веб-трафика. Читатели этого раздела должны ознакомиться с разделом о реализации HTTPS, поскольку многие концепции являются общими и не повторяются здесь, чтобы избежать повторения.Выбор протокола и шифров
Оппортунистический TLS для электронной почты представляет несколько иной сценарий угрозы для HTTPS, что требует другого подхода к выбору протокола и шифров. Ключевые отличия:- атака на более раннюю версию против оппортунистического TLS приводит к обмену данными в виде простого текста в отличие от более слабой версии TLS
- Поддержка TLS почтового сервера не так хорошо гомогенизирована или регулярно обновляется, как поддержка TLS в веб-браузере и программном обеспечении веб-сервера.
- поддерживает последнюю версию TLS (в настоящее время 1.3), TLS 1.2 (для совместимости с MTA-STS) и, возможно, версии TLS, такие же старые, как TLS 1.0
- не поддерживает ни одну версию SSL
- не поддерживает сжатие TLS
- не поддерживают повторное согласование TLS или поддерживают только безопасное повторное согласование, инициированное сервером
- Избегайте шифров, отмеченных как слабые в разделе «Какие наборы шифров и методы шифрования поддерживать» выше.
Сертификаты для почтовых серверов
Почтовые серверы должны иметь действительные сертификаты серверов, выданные известными центрами сертификации, такими как Let's Encrypt, чтобы другие почтовые серверы могли их достоверно аутентифицировать через Интернет. Это становится критически важным при реализации политики MTA-STS.Также применимы советы по получению и обновлению сертификатов в разделе HTTPS выше.
Строгая транспортная безопасность агента пересылки почты
Google, который является одним из ключевых спонсоров MTA-STS и TLS-RPT, предоставил полезное руководство по внедрению MTA-STS [51]. Это руководство можно читать вместе с RFC. Кроме того, существуют инструменты, которые могут помочь проверить правильность вашей политики MTA-STS [52].В следующих разделах представлены дополнительные рекомендации по реализации MTA-STS и TLS-RPT в качестве отправителя электронной почты (информирование ваших почтовых серверов о политиках MTA-STS и TLS-RPT, опубликованных другими) и получателя электронной почты (публикация MTA-STS и TLS-RPT политики).
Обеспечение осведомленности ваших почтовых серверов о MTA-STS
Для обеспечения эффективности чужих политик MTA-STS и предотвращения атак на электронную почту, отправляемую вашей организацией, ваши почтовые серверы должны искать, интерпретировать и применять политики MTA-STS, опубликованные другими владельцами доменов.Ваша способность поддерживать применение политики MTA-STS к исходящей электронной почте будет во многом зависеть от того, предлагает ли ваш почтовый сервер соответствующую функцию или агента политики. Однако, как только это станет доступно, включение его будет сопряжено с относительно низким риском.
Следующий контрольный список поможет в информировании ваших почтовых серверов MTA-STS:
- Определите агент политики или вариант конфигурации для вашего пограничного почтового сервера (почтовые серверы, которые ретранслируют электронную почту, используя записи MX, в другие домены через Интернет), который может опрашивать и применять политики MTA-STS и TLS-RPT.
- Просмотрите, как вы в настоящее время поддерживаете доверенные центры сертификации на почтовом сервере, на котором вы реализуете агент политики MTA-STS, и убедитесь, что существует процесс (в идеале автоматизированный) для согласования этого списка с одним из основных списков разрешенных центров сертификации в веб-браузере.
- Убедитесь, что ваш почтовый сервер поддерживает TLS 1.2.
- Реализуйте агент политики.
- Контролируйте отправку электронной почты вашим почтовым сервером и убедитесь, что она продолжает успешно отправляться в домены с поддержкой MTA-STS.
Публикация политики MTA-STS для вашего домена
Публикация политики MTA-STS для вашего домена - это изменение, которое вы можете немедленно реализовать, если ваши серверы входящей почты (те, которые определены записями MX вашего домена) поддерживают по крайней мере TLS 1.2.Предлагаемый план реализации для публикации политики MTA-STS для вашего домена:
- Проверьте криптографическую конфигурацию и сертификат почтовых серверов вашего домена (серверы, указанные в записи MX вашего домена). Убедитесь, что ваши почтовые серверы:
- поддерживают TLS 1.2 и, в идеале, TLS 1.3, принимая во внимание совет ранее в этом документе, которым вы можете рискнуть, используя версии TLS от 1.0
- отключили слабые шифры и все формы SSL
- настроены с использованием сертификата, который правильно аутентифицирует сервер и выдается известным и доверенным центром сертификации в списке доверенных центров сертификации всех основных веб-браузеров; также рассмотрите возможность автоматизации обновления сертификатов, поскольку после внедрения MTA-STS истечение срока действия сертификата прервет поток электронной почты и, возможно, потребует много времени для определения
- используйте онлайн-инструменты проверки TLS, чтобы убедиться, что почтовый сервер работает должным образом [53].
- Создайте точку отчетности для TLS-RPT (по электронной почте или HTTPS).
- Опубликуйте политику TLS-RPT.
- Отслеживайте отчеты, полученные через вашу точку отчетности, и используйте их, чтобы подтвердить, что другие почтовые серверы могут успешно согласовывать TLS на достаточном уровне при взаимодействии с вашими почтовыми серверами. Если в отчетах выявляются какие-либо проблемы, попробуйте исправить их, прежде чем двигаться дальше.
- Подготовить и опубликовать тестовую политику MTA-STS:
- создать новый веб-сайт с новым сертификатом, выданным известным и доверенным центром сертификации ( mta-sts. <yourdomain> )
- создать политику MTA-STS для тестирования
- опубликуйте свою тестовую политику MTA-STS в стандартном месте на своем новом веб-сайте ( https: // mta-sts. <yourdomain> /.well-known/mta-sts.txt )
- используйте такие инструменты, как веб-браузер, чтобы убедиться, что политика MTA-STS правильно обслуживается при переходе в стандартное расположение.
- Опубликуйте TXT-запись MTA-STS в DNS:
- создать соответствующую запись DNS
- используйте короткий тайм-аут (TTL) для записи DNS, чтобы можно было отменить изменение, если возникнут какие-либо ошибки.
- убедитесь, что он настроен правильно [54].
- Продолжайте отслеживать TLS-RPT на наличие проблем. Убедившись, что все работает, как ожидалось, переходите к тестированию принудительной политики.
- Подготовьте и опубликуйте новую политику применения:
- создать новый файл политики, используя принудительный режим и новый идентификатор политики, используя низкий срок жизни политики, чтобы при необходимости можно было отменить изменения
- опубликуйте новый файл политики в требуемом стандартом месте и настройте запись TXT MTA-STS в DNS на новый ссылочный номер ID.
- После публикации:
- подтвердите правильность конфигурации с помощью инструментов [55]
- убедиться, что электронная почта продолжает поступать, отслеживая журналы почтового сервера
- продолжайте отслеживать TLS-RPT, чтобы определить, сообщают ли какие-либо почтовые серверы в Интернете о проблемах.
- Если вы уверены, что ваша принудительная политика работает должным образом:
- увеличьте время ожидания для вашей политики, обратите внимание, что каждый раз, когда вы настраиваете эту политику, вы также должны изменять идентификатор политики в записи MTA-STS TXT в DNS, чтобы отправляющие почтовые серверы знали об изменении политики
- увеличьте время кеширования для записи TXT MTA-STS в DNS, отметив, что увеличение времени жизни вашей политики, а время кеширования DNS уменьшает возможность для злоумышленников попытаться обойти вашу политику, не давая другим получить вашу политику.
Внедрение MTA-STS с поставщиком услуг
Хотя большинство поставщиков услуг, скорее всего, будут использовать свои почтовые серверы в соответствии с необходимым стандартом, вы все равно должны подтвердить, что они соответствуют и будут поддерживать необходимые стандарты, прежде чем пытаться внедрить MTA-STS. В большинстве случаев реализация TLS_RPT будет безопасным вариантом независимо от позиции вашего поставщика услуг. Это позволит вам узнать, какое шифрование обеспечивают другие почтовые серверы в Интернете при подключении к системам вашего поставщика услуг.
Реализация политики MTA-STS должна в значительной степени соответствовать плану, изложенному в разделе «Публикация политики MTA-STS для вашего домена» выше, хотя это будут указаны почтовые серверы вашего поставщика услуг.
Пограничные случаи
MTA-STS не включает механизма наследования для управления поддоменами. Если для поддоменов требуется защита MTA-STS, им потребуется собственная запись DNS TXT (например, _mta-sts.subdomain.example1.org.au ) и стандартное расположение политики. Однако, как правило, поддомены требуют защиты только в том случае, если они получают электронную почту (т. Е. У них есть опубликованная запись MX).
Пример реализации MTA-STS
Мария является системным администратором для Example1 ( example1.org.au ) и хочет внедрить MTA-STS для защиты конфиденциальности и целостности электронной почты. Входящая электронная почта на Example1 обрабатывается двумя почтовыми серверами, mail1.example1.org.au и mail2.example1.org.ru
example1.org.au. 86400 MX 10 mail1.example1.org.ru
86400 MX 10 mail2.example1.org.ru
Мария начинает с просмотра конфигураций TLS на mail1.example1.org.au и mail2.example1.org.au. Мария подтверждает, что каждый сервер поддерживает необходимые версии TLS, отключает SSL и слабые шифрование и гарантирует, что каждый почтовый сервер имеет сертификат, выданный известным и доверенным центром сертификации. Поскольку Мария не хочет, чтобы потоки электронной почты прерывались из-за истечения срока действия сертификатов, она также тратит время на автоматическое обновление сертификатов.
Когда Мария заканчивает работу, она использует онлайн-инструмент для проверки соответствия предлагаемой криптографии предполагаемой конфигурации и делает дневник, чтобы проверить через 80 дней (поскольку срок действия сертификатов истекает через 90 дней), что сертификаты почтового сервера обновлены правильно.
Изучив IETF RFC 8460, Мария решает использовать электронную почту для получения отчетов и создает для этой цели адрес электронной почты [email protected].
Убедившись, что на этот адрес электронной почты можно получать электронную почту, Мария переходит к следующему шагу и публикует политику TLS-RTP. Мария знает, что публикация адреса TLS-RTP относительно безопасна и устанавливает умеренно долгий тайм-аут в один день (86400 секунд):
_smtp._tls.example1.org.au. 86400 TXT v = TLSRPTv1; rua = mailto: [email protected]
В течение следующей недели Мария просматривает полученные отчеты, пока не убедится, что все работает должным образом.
Затем Мария просматривает IETF RFC 8641, чтобы повторно ознакомиться с его требованиями, а также просматривает другие онлайн-материалы.
Мария начинает разрабатывать политику MTA-STS на основе своего понимания RFC 8641 и примеров, которые она видела в других местах. Мария решает установить время жизни кэша политики на 600 секунд (десять минут) во время тестирования. Мария также решает указать серверы MX, используя синтаксис MX с подстановочными знаками, что позволяет ей добавлять или изменять серверы MX позже при условии, что она будет поддерживать тот же стандарт именования. Таким образом, результирующая политика:- версия: STSv1
- режим: тестирование
- mx: * .example1.org.ru
- max_age: 600
Составив проект политики MTA-STS, Мария переходит к следующему шагу - созданию необходимого веб-сайта для размещения файла политики. Мария отмечает, что на веб-сайте должен размещаться только статический файл, и рассматривает возможность размещения контента на сервисе корзины поставщика облачных услуг в сочетании с сетью доставки контента для обеспечения TLS, но в конце концов решает создать новый веб-сайт на существующем веб-сервере. Таким образом, Мария:
- создает новый сайт на сервере для mta-sts.example1.org.ru
- создает подкаталог. well-known и помещает туда файл политики как mta-sts.txt
- настраивает TLS на веб-сайте с помощью подстановочного сертификата (* .example1.org.ru), который у нее уже есть на веб-сервере для других веб-сайтов.
- создает запись DNS A, указывающую mta-sts.example1.org.au на IP-адрес веб-сервера
- использует веб-браузер во внешнем соединении, чтобы гарантировать, что
обслуживает файл политики MTA-STS, созданный ею ранее.
Выполнив все предварительные требования, Мария теперь готова запустить политику MTA-STS, опубликовав запись DNS, чтобы указать, что политика доступна. Мария хочет иметь возможность быстро изменить политику в случае возникновения проблем, поэтому она выбрала низкое время кеширования DNS (также известное как TTL), равное 300 секунд (5 минут). Из RFC она знает, что значение идентификатора в записи TXT не важно, за исключением того, что его изменение указывает на доступность новой политики. Мария отмечает на примерах, которые она видела, что использование метки времени в формате ГГГГММДДЧЧММ (например, 202006071753 для 17:53 07.06.2020) кажется обычной практикой, и решает применить ее.
_mta-sts.example1.org.au. 300 TXT v = STSv1; id = 202006071753
Мария использует онлайн-инструмент, чтобы подтвердить правильность конфигурации.
Мария не ожидает каких-либо проблем с потоком электронной почты, поскольку политика находится в режиме тестирования, но, тем не менее, внимательно отслеживает потоки электронной почты сразу после этого, а также отслеживает журналы веб-сервера, чтобы определить, запрашивается политика MTA-STS.
В течение следующей недели Мария внимательно следит за почтовыми потоками, а также просматривает любые отчеты SMTP TLS, полученные по адресу, который она создала ранее. Через неделю проблем не было, и Мария решает применить принудительную политику. Таким образом, Мария открывает файл политики на веб-сайте mta-sts.example1.org.au и меняет режим на принудительное, но оставляет max_age прежним, чтобы она могла быстро отменить изменение, если это необходимо. Теперь файл гласит:- версия: STSv1
- режим: принудительно
- mx: * .example1.org.ru
- max_age: 600
Настроив политику, Мария уведомляет об изменении другие почтовые серверы в Интернете, изменяя значение идентификатора в записи TXT _mta-sts.example1.org.au , но оставляет время кеширования DNS на относительно низком уровне 300 секунд, чтобы она могла отмените любые изменения, если есть проблемы.> / p>
Мария использует онлайн-инструмент, чтобы подтвердить правильность конфигурации.
Мария знает, что это изменение может повлиять на поток электронной почты, поэтому, помимо тщательного отслеживания потоков электронной почты сразу после этого, она также использует онлайн-учетную запись веб-службы электронной почты, поддерживающей MTA-STS, для отправки тестового электронного письма на свой адрес электронной почты в example1.org.ru и подтверждает получение.
С введением обязательной политики Мария внимательно следит за потоками электронной почты в течение следующего месяца. Убедившись, что все работает как надо, Мария вносит два последних изменения:- она устанавливает max_age в файле политики mta-sts.txt на 86 400 (один день)
- она настраивает номер идентификатора в _mta-sts.example1.org.ru на текущее время в формате ГГГГММДДЧЧММ, чтобы уведомить другие почтовые серверы в Интернете об изменении.
Наконец, Мария делает пометку в своем дневнике, чтобы пересмотреть настройку max_age через шесть месяцев и поднять ее до недели, месяца или даже больше в зависимости от того, возникнут ли какие-либо проблемы с потоком электронной почты.
Приложение А. Допустимые наборы шифров
В этом приложении содержится список допустимых комплектов шифров, в том числе:- комплекты шифров, которые полностью соответствуют ISM
- комплекты шифров, частично совпадающие с ISM
- наборы шифров, которые организации могут пожелать использовать в зависимости от решения по управлению рисками, касающегося потребностей и ситуации их пользователей.
Шифры перечислены в порядке предпочтения (т.е. веб-серверы должны отдавать предпочтение шифрам, идущим сверху вниз).
Наборы шифров для TLS 1.3
Для TLS 1.3 рекомендуются следующие наборы шифров:- TLS_AES_256_GCM_SHA384
- TLS_AES_128_GCM_SHA256
- TLS_AES_128_CCM_SHA256
- TLS_AES_128_CCM_8_SHA256.
Организации могут пожелать принять решение по управлению рисками по использованию TLS_CHACHA20_POLY1305_SHA256. Этот набор шифров может обеспечить лучшую производительность на платформах, не имеющих аппаратной поддержки Advanced Encryption Standard (AES), таких как устройства на базе ARM, такие как мобильные телефоны, планшеты и недорогие ноутбуки. Однако, хотя у этого набора шифров нет публично раскрытых слабых мест, он не подвергался тому же стандарту проверки и анализа, что и рекомендуемые комплекты шифров.
Наборы шифров для TLS 1.2
Для TLS 1.2 рекомендуются следующие наборы шифров:- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_DHE_DSS_WITH_AES_128_GCM_SHA256
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_CCM
- TLS_DHE_RSA_WITH_AES_256_CCM
- TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8
- TLS_DHE_RSA_WITH_AES_256_CCM_8
- TLS_ECDHE_ECDSA_WITH_AES_128_CCM
- TLS_DHE_RSA_WITH_AES_128_CCM
- TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
- TLS_DHE_RSA_WITH_AES_128_CCM_8.
Организации могут пожелать принять решение по управлению рисками при использовании следующих комплектов шифров, поскольку они могут обеспечить лучшую производительность на платформах, не имеющих аппаратной поддержки AES, таких как устройства на базе ARM, такие как мобильные телефоны, планшеты и недорогие ноутбуки. Однако, хотя в этих наборах шифров нет публично раскрытых недостатков, они не подвергались тому же стандарту проверки и анализа, что и рекомендуемые наборы шифров:
- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_CAMELLIA_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384
- TLS_DHE_DSS_WITH_CAMELLIA_256_GCM_SHA384
- TLS_DHE_DSS_WITH_ARIA_256_GCM_SHA384
- TLS_DHE_RSA_WITH_CAMELLIA_256_GCM_SHA384
- TLS_DHE_RSA_WITH_ARIA_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256
- TLS_DHE_DSS_WITH_CAMELLIA_128_GCM_SHA256
- TLS_DHE_DSS_WITH_ARIA_128_GCM_SHA256
- TLS_DHE_RSA_WITH_CAMELLIA_128_GCM_SHA256
- TLS_DHE_RSA_WITH_ARIA_128_GCM_SHA256.
Last edited by a moderator:
