Шифры безопасности и их реализация в Citrix ADC

Многие специалисты по информационным технологиям отлично ориентируются в основах шифрования SSL/TLS, а также в окружающих терминах, таких как «Heartbleed» и «POODLE». Но теория и реальный мир в ряде аспектов – это две абсолютно разные вещи, и опросы клиентов Citrix ADC показали, что многие используют конфигурацию из коробки для своих критических приложений. В том числе это касается и выбора наборов шифров SSL для коммуникаций клиентов с ADC (Client-to-ADC) и ADC с серверами (ADC-to-Server).

Корректный выбор и применение наборов шифров крайне важен не только для безопасности бизнес-приложений, но и для обеспечения доступности пользовательских возможностей. Далее мы рассмотрим, как корректно выбирать наборы шифров для окружений и управлять ими при помощи Citrix ADC, обеспечивая безопасность и доступность окружений.

Структура набора шифров (Cipher Suite).

Рассмотрим набор шифров SSL на примере набора от TLS 1.2.

Наиболее важными частями в наборе шифров (Cipher Suite) являются обмен ключами (Key Exchange) и массовое шифрование (Bulk Encryption). Которые определяют способ начального обмена ключами шифрования SSL и последующее шифрование данных во время сессии. Секция сигнатуры (Signature) менее интересна в разрезе нашего рассмотрения, но она оказывает непосредственное влияние на производительность.

Обмен ключами (Key Exchange):

• RSA – один из старейших методов обмена ключами, он обычно используется для обеспечения совместимости со старыми клиентами, его использование постепенно сокращается.
• DHE – обмен Диффи-Хеллмана (Diffie-Hellman) позволяет двум участникам независимо друг от друга сгенерировать общий секрет без риска компрометации.
• ECDHE – Версия с эллиптической кривой для DHE обладает свойствами DHE, но при этом использует меньше вычислительных ресурсов.

Нужно отметить, что DHE и ECDHE обеспечивают прямую секретность – это значит, что даже если злоумышленник получит информацию из секретного ключа, он не сможет подобрать ключи от индивидуальной сессии, записанной ранее. При использовании обмена ключами RSA, если злоумышленник взломает ключ сертификата, то он потенциально сможет расшифровать все исторические и будущие передачи данных.

Массовое шифрование (Bulk Encryption):

• RC4 – это устаревший шифр, который использовался из-за его простоты и скорости, но из-за серьезных уязвимостей лучше отказаться от его использования.
• DES – это ещё один устаревший шифр, обладающий ключом с короткой длиной, который также не следует использовать.
• 3DES – запущенный три раза DES для достижения дополнительной безопасности. Постепенно от него отказываются и единственный сценарий, когда его использование оправдано – это обеспечение совместимости.
• AES – наиболее популярный шифр данных, используемый в SSL.
• ChaCha20 – современный, безопасный, быстрый шифр, который набирает популярность.

К счастью, стандарты TLS 1.3 немного проще за счёт того, что они поддерживают только эфемерный обмен ключами Диффи-Хеллмана (Diffie-Hellman), нужно только перечислить шифр массового шифрования данных и алгоритм аутентификации сообщений. Пример шифра TLS 1.3: TLS_AES_256_GCM_SHA384.

Теперь, когда мы прошлись по основам, рассмотрим, как определяются наборы шифров для соединений SSL. 

Процесс квитирования SSL.

В процессе начального квитирования SSL, клиент отправляет список шифров на сервер, в порядке предпочтения. Это сообщение называется clientHello, его можно легко увидеть в трассировке Wireshark, если открыть первый пакет, отправленный от клиента к серверу.

Пример, секции наборов шифров (Cipher Suites):

На снимке экрана, клиент предпочитает наборы шифров TLS 1.3, затем запрашивает шифры ECDHE от TLS 1.2, если соединение TLS 1.3 невозможно установить.

Наиболее важная вещь, которую нужно отметить – сервер SSL/TLS отвечает за выбор набора шифров. Это значит, что клиенты подключающиеся к Citrix ADC, находятся под властью машины, соответственно, очень важно корректно настроить наборы шифров для ADC. В противном случае опубликованные приложения подвержены риску компрометации.

Citrix ADC и группы/наборы шифров.

Как же все вышесказанное применяется по отношению к Citrix ADC? 

В первую очередь необходимо запомнить тот факт, что Citrix ADC одновременно выступает как клиентом, так и сервером для разных потоков подключений. В терминологии ADC – это типы подключений SSL: BackEnd и FrontEnd.

Предпочтительный путь настройки целостных параметров ADC – это использовать профили SSL (SSL Profiles).

Можно добавить профили SSL для подключений FrontEnd и BackEnd, которые будут использовать виртуальные серверы (vServer) и SNIP для предоставления соединений и подключения к клиентам/сервисам.

Так же в профиле SSL в разделе продвинутых параметров (Advanced Settings) можно добавить группы шифров SSL.

Здесь необходимо установить наиболее безопасную группу шифров для использования по умолчанию во всех вновь создаваемых виртуальных серверах (vServer) на Citrix ADC. Важно отметить, что наборы шифров, перечисленные выше по списку, имеют большее предпочтение. Это значит, что если клиент поддерживает первый набор шифров в списке, то Citrix ADC его и выберет.

Рассмотри группу шифров по умолчанию (DEFAULT) в Citrix ADC.

На самом деле, в верху списка размещаются несколько шифров TLS 1.0, что означает их предпочтение в случае, если клиент их поддерживает. Именно поэтому важно проверить существующие профили/группы и создать собственные.

Рекомендации.

Золотое правило настройки: «Всегда размещайте более безопасные наборы шифров (Cipher Suite) в начале списка предпочтений (Preference List)».

Это значит, что всегда необходимо размещать наборы шифров, TLS 1.3 или TLS 1.2 с использованием обмена ключами ECDHE в начале списка предпочтений. Звучит достаточно просто, но есть ряд нюансов и исключений, которые необходимо учесть. Тем не менее, безопасность должна оставаться в приоритете.

Рекомендации по наборам шифров:

• Если это возможно, придерживайтесь золотого правила.
• Создавайте настраиваемую группу шифров по умолчанию для обоих типов подключений (FrontEnd и BackEnd). Не следует использовать группу шифров Citrix ADC по умолчанию без тщательной проверки.
• Создайте дополнительные настраиваемые группы шифров для каждого сервиса, требующего более или менее строгой безопасности.
• Если вы не уверены в том, что считать безопасным, а что нет, можете обратиться к новейшему списку предпочтений Windows Server 2022, чтобы увидеть, что Microsoft считает безопасным.

Предостережения по наборам шифров:

• Не используйте наборы шифров SSL3, TLS1 и TLS1.1 (если это возможно).
• Не размещайте небезопасные наборы шифров в начале групп шифров по умолчанию для исключительных сценариев. Вместо этого, используйте настраиваемые группы шифров для реализации требований и применяйте их только по необходимости.
• При размещении небезопасных наборов шифров убедитесь, что они находятся внизу списка.
• Не используйте уязвимые шифры для массового шифрования (Bulk Encryption), такие как RC4, DES или 3DES, если это возможно.

Совместимость и производительность.

Есть только две причины, по которым отходят от золотого правила (Всегда размещайте более безопасные наборы шифров в начале списка предпочтений): совместимость и производительность.

Совместимость (Compatibility).

Существуют ситуации, в большинстве своем связанные с подключениями клиентов (FrontEnd), когда Citrix ADC должен обслуживать клиентов со старыми операционными системами или приложениями, которые требуют устаревших версий TLS и/или наборов шифров. В таких ситуациях необходимо разобраться в бизнес-обоснованиях и совместно с командой обеспечения безопасности определить риски и дальнейшие шаги. Это очень важно, чтобы лица, принимающие решения, понимали риски, связанные с использованием небезопасных наборов шифров. Не следует принимать такое решение самостоятельно, не согласовав его со всеми заинтересованными сторонами.

Совместимость не является большой проблемой для фоновых соединений (BackEnd), в виду того, что коммуникации между серверами хорошо контролируются во внутренних сетях компании различными компонентами. Особых требований по снижению уровня безопасности также нет, когда любые серверные конфигурации могут быть изменены в соответствии с требованиями.

Производительность (Performance).

Второй важной вещью при выборе наборов шифров является производительность. Совершенно точно никто не хочет получить отказ в обслуживании для того, что необходимо защитить.

Размеры ключей могут играть важную роль в производительности. Ключи шифрования большего размера – более безопасны, но во многих случаях стараются использовать достаточную, а не максимально возможную безопасность, с целью обеспечения необходимого уровня производительности. Например, ключ RSA с длиной 2048, считается безопасным, но при этом он меньше, чем ключи с длиной 3072 и 4096. Ключи большего размера предоставляют более высокий уровень безопасности, который, как правило, не требуется на сегодняшний день (или в ближайшем будущем). При этом увеличенная длина ключа будет создавать дополнительную нагрузку на вычислительные ресурсы при установке соединения SSL.

Тип обмена ключами также очень важен. Переход от RSA к ECDHE, зачастую, считается правильным выбором, для получения улучшенной безопасности. Также, благодаря свойствам эллиптической кривой, можно уменьшить общую длину ключа.

Несмотря на то, что это все правда, переход к обмену ключами DHE или ECDHE может существенно сократить общее количество запросов в секунду, которое система, такая как Citrix ADC сможет поддерживать. Это в двойне правда для старого оборудования, которое не имеет аппаратной поддержки для расчета эллиптических кривых, такого как аппаратные платформы (MPX) Citrix ADC 5900/8600/26000 с их чипсетами Intel Coleto Creek.

В таком случае, к вопросу выбора предпочтительных наборов шифров нужно подойти максимально серьезно (особенно для соединений FrontEnd), или можно оказаться в ситуации, когда пострадают возможности пользователей из-за перегруженности вычислительных ресурсов ADC.

В случае, когда вы упираетесь в лимиты старого оборудования, разумным шагом будет рассмотреть возможность обновления.

Заключение.

Наборы шифров и группы на самом деле важны при управлении контроллерами доставки приложений (ADC). Несмотря на простоту золотого правила, существует множество аспектов, которые нужно учесть. Необходимо совместно со службой информационной безопасности и лицами, принимающими решения, выработать взвешенное решение для защиты критических для бизнеса приложений.

P.S. Если тема траффика HTTPS вам интересна, я могу порекомендовать несколько моих статей по этой тематике: «HTTP3, TLS 1.3 и Citrix ADC» и «Использование Citrix ADC для развертывания сетевого моста QUIC».

Практический аспект настройки SSL/TLS для веб-серверов можно посмотреть в веб-кастах «Настройка SSL/TLS для Apache в CentOS 8» и «TLS-шифрование NGINX в CentOS 8».