Как я могу решить, какие ssl_protocols и ssl_ciphers устанавливать с помощью nginx?

На этот вопрос нет единственно правильного ответа, потому что выбор комплектов шифров должен быть подходящим компромиссом между безопасностью и совместимостью. В Рекомендации Mozilla по TLS на стороне сервера ссылка на генератор конфигурации объясняет назначение различных профилей:

• Современная совместимость. Для служб, которым не требуется обратная совместимость, параметры ниже обеспечивают более высокий уровень безопасности. Эта конфигурация совместима с Firefox 27, Chrome 30, IE 11 в Windows 7, Edge, Opera 17, Safari 9, Android 5.0 и Java 8.

• Промежуточная совместимость (дефолт). Для служб, которым не требуется совместимость с устаревшими клиентами (в основном WinXP), но которые все же должны поддерживать широкий спектр клиентов, рекомендуется эта конфигурация. Он совместим с Firefox 1, Chrome 1, IE 7, Opera 5 и Safari 1.

• Старая обратная совместимость. Это старый набор шифров, который работает со всеми клиентами до Windows XP / IE6. Его следует использовать только в крайнем случае.

Добавление TLS 1.3 к этим рекомендациям было выполнено обсуждение, но еще не добавлен. Это рассуждение относится к 2016 году, до того, как TLS 1.3 был предложен в качестве стандарта в RFC 8446:

jvehent от 27 декабря 2016 г. Автор

Не думаю, что здесь стоит рекомендовать экспериментальные версии. Мы ждали, пока CHACHA20 будет стандартизирован, прежде чем добавить его в рекомендации, то же самое относится и к TLS1.3.

Аналогичным образом Qualys SSL Labs опубликовала Рекомендации по развертыванию SSL и TLS. Поскольку последний раз он (по состоянию на июнь 2019 г.) обновлялся в мае 2017 г., TLS 1.3 упоминается только как будущий протокол, но объясняются проблемы со старыми версиями, предшествующими TLS 1.2:

TLS v1.2 должен быть вашим основным протоколом, потому что это единственная версия, которая предлагает современное аутентифицированное шифрование (также известное как AEAD). Если вы не поддерживаете TLS v1.2 сегодня, ваша безопасность будет недостаточной.

Для поддержки старых клиентов вам может потребоваться продолжить поддержку TLS v1.0 и TLS v1.1 на данный момент. Однако в ближайшем будущем вы должны запланировать отказ от TLS v1.0. Например, стандарт PCI DSS потребует от всех сайтов, принимающих платежи по кредитным картам, прекратить поддержку TLS v1.0 к июню 2018 года.

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

Серверный тест SSL Labs обновляется более регулярно и указывает на дополнительные возможные недостатки:

• Все TLS_RSA ciphersuites были отмечены как WEAK, потому что они не обеспечивают прямой секретности: если закрытый ключ будет скомпрометирован в будущем, весь записанный трафик может быть расшифрован с его помощью.
• Все шифровальные наборы, использующие Цепочка блоков шифра CBC автоматически не являются слабыми, но было так много реализаций, уязвимых для дополнение атак оракула что они решили пометить их все как СЛАБЫЕ.

У нас также есть лучшая текущая практика RFC 7525 с мая 2015 г .; Рекомендации по безопасному использованию безопасности транспортного уровня (TLS) и безопасности транспортного уровня дейтаграмм (DTLS). это Раздел 4.2 дает рекомендации, аналогичные современной совместимости Mozilla и тесту сервера SSL Labs:

С учетом вышеизложенного РЕКОМЕНДУЕТСЯ реализация и развертывание следующих комплектов шифров:

• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Эти наборы шифров поддерживаются только в TLS 1.2, поскольку они представляют собой алгоритмы аутентифицированного шифрования (AEAD) [RFC5116].

Исходя из всего этого, было бы неплохо "настроить под свои нужды"современный профиль, например,

• удаление шифровальных наборов на основе CBC из современного профиля совместимости, т.е. удаление ECDHE-ECDSA-AES256-SHA384, ECDHE-RSA-AES256-SHA384, ECDHE-ECDSA-AES128-SHA256, ECDHE-RSA-AES128-SHA256
• добавление наборов шифров DHE, если они имеют длину ключа не менее 2048 бит и используют режим GCM: DHE-RSA-AES256-GCM-SHA384, DHE-RSA-AES128-GCM-SHA256.

Раздел «Имитация рукопожатия» в тесте сервера SSL Labs помогает указать браузеры, которые не поддерживаются данной конфигурацией. Вам решать, важно поддерживать их или нет, и добавлять самый надежный шифровальный набор, доступный в этом браузере.

Стоит ли ждать рекомендаций Mozilla по внедрению TLS 1.3 или нет, также зависит от мнения. Хорошая новость для вас заключается в том, что в TLS 1.3 полностью удалена поддержка всех устаревших алгоритмов, что затрудняет выбор плохих наборов шифров. Из RFC 8446, 1.2. Основные отличия от TLS 1.2:

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