У меня есть вариант использования, противоположный большинству: я хотел бы реализовать очень слабые шифры SSL во имя производительности с возможностью вернуться к более сильным шифрам, если клиент запросит это.
Предыстория: у меня есть общедоступный веб-сервер, который получает огромное количество POST-трафика от тысяч удаленных клиентов, причем каждый POST-запрос довольно мал. Клиент один раз загрузит полезную нагрузку и отключится. Сервер принимает тысячи этих подключений в минуту, поэтому накладные расходы на согласование SSL складываются.
Данные, о которых идет речь, НЕ должны быть безопасными; Причина использования HTTPS вообще заключается в том, что трафик исходит из тега JavaScript на данном веб-сайте, и если указанный сайт использует HTTPS, то наш дополнительный трафик также должен использовать HTTPS, чтобы предотвратить предупреждение о смешивании безопасного и небезопасного контента. Опять же, безопасность данных в этом соединении совершенно не важна, даже если "родительский" сайт по какой-либо причине защищен SSL.
Из-за этого для меня имеет смысл предоставлять клиентам самый слабый из возможных шифров, сохраняя при этом полную совместимость с браузерами. Я также хотел бы предложить возможность повышения безопасности до полного ECDHE, если потребуется, просто для удовлетворения большего количества клиентов, заботящихся о безопасности, но определенно как дополнительный вариант.
Несколько лет назад какой-то вариант RC4 отвечал всем требованиям, но, поскольку сегодня он повсеместно считается небезопасным, я обеспокоен тем, что совместимость браузеров может стать проблемой. После этого - какие шифры предложат мне функции, которые я ищу выше, с максимальной скоростью?
Данные, о которых идет речь, НЕ должны быть безопасными ... предотвратить предупреждение о смешивании.
Я думаю, вам, вероятно, следует понять причину этих предупреждений, а не просто игнорировать их как можно лучше. Если контент на безопасном сайте добавлен с незащищенного сайта, это может повлиять на безопасность исходного сайта.
Сервер принимает тысячи этих подключений в минуту, поэтому накладные расходы на согласование SSL складываются.
Быстрый шифр обычно не снижает значительно накладные расходы на согласование SSL. В основном используются шифры после переговоры выполнены и имеют лишь небольшое влияние на производительность. Некоторая часть шифра имеет отношение к рукопожатию (обмену ключами), но если вы не выберете очень медленный обмен ключами (см. Ниже), основное влияние на производительность будет иметь множественные внутренние циклы обмена, необходимые для согласования. Их можно уменьшить только в том случае, если вы поддерживаете повторное использование сеансов, так что полное рукопожатие требуется только для первого запроса, а в следующий раз, когда тот же клиент подключается, можно выполнить менее затратное возобновление сеанса. HTTP keep-alive тоже может очень помочь. Конечно, обе эти оптимизации работают, только если у вас действительно есть несколько запросов от одного и того же клиента.
Есть несколько шифров с очень медленным обменом ключами, которые вы, вероятно, не захотите использовать в вашем случае. Все шифры DHE- * имеют большое влияние на производительность, но обладают преимуществом обеспечения прямой секретности. Вы получаете такое же преимущество с шифров ECDHE, не оказывая слишком большого влияния на производительность современного оборудования, но все же накладные расходы остаются. Используя шифры вроде AES128-GCM-SHA256 должен быть хорошим выбором как с точки зрения производительности, так и с точки зрения безопасности.
В конце концов, выбор шифра зависит также от клиентов, которых вы используете. Пока RC4-SHA быстро он считается небезопасным, и все больше и больше клиентов отключают его. Таким образом, вы можете и с быстрым сервером, который никто не может использовать, потому что браузеры отключили небезопасные шифры.
Самым быстрым будет eNull. Включать eNull в ssl_ciphers, пытаться aNULL:eNULL:MD5:LOW:HIGH для вашей строки шифра. Однако обычно вы собираетесь согласовать самый высокий поддерживаемый шифр. Поэтому вы можете захотеть ограничить его, используя !HIGH, но обязательно тщательно это протестируйте. Вам, по крайней мере, нужно будет сохранять LOW, поскольку я считаю, что большинство браузеров вообще откажутся от использования нулевого и md5-шифра.
В зависимости от вашей срочности вы можете дождаться принятия «Сальса20» и «ЧаЧа» в частности, он предназначен для прямой замены RC4 с точки зрения производительности. Однако на данный момент только Google Chrome и последние версии ОС Android поддерживают его на стороне клиента, и его еще нет в OpenSSL, поэтому серверы еще не поддерживают. В противном случае я согласен с другими по AES-IN.
https://discussions.qualys.com/thread/16005 перечисляет некоторые тесты как массовых операций шифрования, так и обмена ключами. Для массовых шифров aes128-ccm кажется самым быстрым, а для обмена ключами ecdhe (с nist p256) немного быстрее, чем 2048-битный dhe, но обмен ключами rsa происходит немного быстрее. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5551094/ перечисляет сравнение методов обмена ключами показывает, что обмен ключами Curve25519 (он же X25519) значительно быстрее, чем nist p256)
Собирая все это вместе, с современным процессором и библиотекой ssl, лучше всего, вероятно, будет TLS_ECDHE_ECDSA_WITH_AES_128_CCM (наборы GCM почти такие же быстрые и более широко используются) с X25519 для обмена ключами. В интересах совместимости клиентов вы также можете предложить TLS_RSA_WITH_AES_128_CBC_SHA, который использует обмен ключами RSA. Вы также можете предложить наборы RC4, но браузеры могут начать отклонять этот алгоритм. В конечном итоге это зависит от оборудования вашего сервера, поэтому, вероятно, будет хорошей идеей попробовать протестировать несколько наборов шифров и посмотреть, сколько соединений в секунду вы можете сделать.