Конфигурация сервера - снижается или скомпрометирована безопасность, если включено слишком мало параметров шифрования SSL?
Когда я ввожу свою версию сервера (NGINX 1.16.0) и версию OpenSSL (1.0.2k) в Mozilla SSL Configuration Generator , я получаю длинный список SSL-шифров.
Например,
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES128-GCM-SHA256: ECDHE-ECDSA-AES256-GCM-SHA384: ECDHA -AES256-GCM-SHA384: ECDHE-ECDSA-CHACHA20-POLY1305: ECDHE-RSA-CHACHA20-POLY1305: DHE-RSA-AES128-GCM-SHA256: DHE-RSA-AES256-GCM-SHA384 Однако, когда я;
Cipherli.st предоставляет только два SSL-шифра для Nginx.
ssl_ciphers EECDH + AESGCM: EDH + AESGCM;
Сокращение числа доступных шифров снижает или ставит под угрозу безопасность? Если я предлагаю клиентам меньше вариантов шифрования, это улучшит производительность или изменит какие-то другие важные характеристики?
Одно из допущений в TLS (и SSL до этого) состоит в том, что сервер и клиент могут (и обычно должны) согласовывать и согласовывать шифр, который они взаимно поддерживают при инициировании безопасного соединения.
Причина этого в основном в совместимости: она позволяет постепенно вводить новые шифры, а не нарушать связь между клиентами и серверами, которые еще не поддерживают этот новый шифр.
Вот что произошло бы, если бы использовался только один шифр без согласования. Затем, когда одна сторона решает отказаться от старого шифра и обновляется до нового, и они делают это без согласования с другими сторонами, соединение разрывается.
В одной организации координация одновременного обновления и серверов, и клиентов - это уже довольно сложная задача, хотя и возможная, в Интернете в целом такое масштабное обновление, конечно, почти невозможно.
Таким образом: согласование шифров хорошее. (По крайней мере, для совместимости.)
Уменьшает ли меньшее количество доступных шифров или ставит под угрозу безопасность?
Нет. Число шифров не определяет безопасность.
Это сами шифры, которые обеспечивают безопасность.
Хотя некоторые шифры относительно более безопасны, чем другие (разные алгоритмы или один и тот же алгоритм с большей длиной ключа и способностью обеспечивать прямую безопасность могут сделать одни более безопасными, чем другие), другие же слабые или даже сломанный, нет дополнительных преимуществ безопасности в поддержке только нескольких, а не всех шифров, которые соответствуют вашим требованиям безопасности.
(С небольшим предупреждением, что каждый поддерживаемый вами шифр также должен иметь реализацию в Таким образом, больше шифров == больше кода == повышается вероятность ошибок и ошибок реализации ...)
Если я предлагаю клиентам меньше вариантов шифрования, улучшается ли это производительность или регулируется какая-то другая важная характеристика?
Нет, хотя разные шифры будут иметь существенно разную статистику производительности и разные варианты использования, за исключением оговорки выше о том, что меньшее количество шифров означает меньше кода и меньший риск для эксплойтов нулевого дня, количество шифров , которое вы поддерживаете на стороне сервера, никак не влияет на производительность . Нет никакого дополнительного выигрыша в производительности от поддержки только нескольких, а не всех шифров, которые отвечают вашим требованиям безопасности.
Меньшее количество поддерживаемых шифров означает меньшую совместимость. (Потому что вы обычно ограничиваете серверы новейшими и самыми сильными шифрами, которые старые клиенты могут не поддерживать и / или которые могут быть для них слишком дорогими в вычислительном отношении.)
Запишите строки User-Agent и сделайте инвентаризацию того, какое влияние окажет обновление настроек безопасности веб-серверов, предварительно обратившись к таблице, такой как Возможности пользовательского агента SSL Lab .