Конфигурация сервера. Снижается ли или ставится ли под угрозу безопасность, если включено слишком мало параметров шифрования SSL?

Конфигурация сервера. Снижается ли или ставится ли под угрозу безопасность, если включено слишком мало параметров шифрования SSL?

Когда я ввожу версию своего сервера (NGINX 1.16.0) и версию OpenSSL (1.0.2k) вГенератор конфигурации Mozilla SSLЯ получаю длинный список SSL-шифров.

Например,

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;

Однако, когда я посещаюCipherli.stон предоставляет только два SSL-шифра для Nginx.

ssl_ciphers EECDH+AESGCM:EDH+AESGCM;

Снижает ли или ставит под угрозу безопасность меньшее количество доступных шифров? Если я предлагаю клиентам меньше вариантов шифров, улучшает ли это производительность или корректирует ли какую-то другую важную характеристику?

решение1

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

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

Таким образом: согласование шифра — это хорошо. (По крайней мере, для совместимости.)

Снижает ли или ставит под угрозу безопасность меньшее количество доступных шифров?

Нет.количество шифровне определяет безопасность.

Безопасность обеспечивают сами шифры.

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

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

Если я предложу клиентам меньше вариантов шифрования, улучшит ли это производительность или изменит ли какую-то другую важную характеристику?

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

Меньшее количество поддерживаемых шифров означает меньшую совместимость.(Поскольку вы обычно ограничиваете серверы новейшими и самыми надежными шифрами, которые старые клиенты могут не поддерживать и/или которые могут быть слишком вычислительно затратными для них.)
Запишите строки User-Agent и составьте список того, какое влияние окажет обновление настроек безопасности веб-серверов, ссылаясь на таблицу, например:Возможности пользовательского агента SSL Lab заранее.

Связанный контент