Переговоры по рукопожатию SSL на Nginx ужасно медленные


17

Я использую Nginx в качестве прокси для 4 экземпляров Apache. Моя проблема в том, что согласование SSL занимает много времени (600 мс). Посмотрите на это в качестве примера: http://www.webpagetest.org/result/101020_8JXS/1/details/

Вот мой Nginx Conf:

user www-data;
worker_processes  4;


events {
    worker_connections 2048;
    use epoll;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;
    access_log  /var/log/nginx/access.log;
    sendfile        on;
    keepalive_timeout  0;
    tcp_nodelay        on;
    gzip  on;
    gzip_proxied any;
    server_names_hash_bucket_size 128;


}

upstream abc {
     server 1.1.1.1 weight=1;
     server 1.1.1.2 weight=1;
     server 1.1.1.3 weight=1;


 }


server {
    listen   443;
    server_name  blah;

    keepalive_timeout 5;

    ssl  on;
    ssl_certificate  /blah.crt;
    ssl_certificate_key  /blah.key;
    ssl_session_cache  shared:SSL:10m;
    ssl_session_timeout  5m;
    ssl_protocols  SSLv2 SSLv3 TLSv1;
    ssl_ciphers RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
    ssl_prefer_server_ciphers   on;

    location / { proxy_pass http://abc;

                 proxy_set_header X-Real-IP  $remote_addr;
                 proxy_set_header Host $host;
                 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    }

}

Машина представляет собой VPS на Линоде с 1 ГБ ОЗУ. Может кто-нибудь сказать, почему SSL рукопожатие занимает много лет?

Ответы:


11

Вам необходимо отключить шифры "эфемерный Диффи-Хеллман". Браузеры не используют их в любом случае, но openSSL будет использовать при работе с такими инструментами, как cURL или apachebench. Я держу пари, что webpagetest.org использует их.

Смотрите эту тему для более подробной информации.

Я лично использую эти настройки в nginx, чтобы принудительно использовать самые быстрые, но при этом безопасные шифры SSL на основе предпочтений сервера, а не браузеров:

Обновление 2014-01-13: этот совет изменился, учитывая недавние атаки на RC4, обновления браузера, защищающие от BEAST, и более широкую доступность TLS v1.2 на клиентах и ​​серверах.

Обновлено 2015-10-16: текущие настройки TLS для Nginx 2015-10-16 в соответствии с рекомендациями CloudFlare . Пожалуйста, проверьте предыдущую ссылку на наличие обновлений, поскольку TLSv1, вероятно, будет удален из рекомендуемой конфигурации в какой-то момент. Текущие настройки отключают SSLv3 и RC4 в соответствии с текущей практикой и последней версией PCI-DSS на эту дату.

ssl_protocols               TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers                 EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
ssl_prefer_server_ciphers   on;

Это заменяет предыдущий совет в этом ответе, который был удален, чтобы избежать путаницы.


RC4 небезопасен и не подходит для использования в TLS. «Хотя алгоритм RC4, как известно, имеет множество криптографических слабостей (см. [26] для превосходного обзора), ранее не было исследовано, как эти слабости могут быть использованы в контексте TLS. Здесь мы показываем, что новые и недавно обнаруженные искажения в потоке ключей RC4 создают серьезные уязвимости в TLS при использовании RC4 в качестве алгоритма шифрования ». См. О безопасности RC4 в TLS и WPA .

2
@noloader, что атака Rc4 была объявлена ​​спустя годы после моего поста; до самого недавнего времени большинство криптографов рекомендовали RC4 поверх AES из-за атаки BEAST на TLS v1.0 и более ранних версий. Теперь, когда большинство браузеров защищено от BEAST на стороне клиента, и были предприняты дальнейшие атаки на RC4, совет изменился. В этом посте вы
найдете

Боже мой! Прости за это. Я не думал проверять даты. Сожалею.

5

У вас может не быть хорошего источника энтропии. Существует /dev/urandom? Если нет, Nginx заблокирует чтение /dev/random.

Каков размер вашего ключа? Дольше медленнее.

Попробуйте straceпроцессы, чтобы увидеть, что они делают.


+1 Похоже, это хорошая возможность, поскольку на VPS часто отсутствует случайность
Кайл Брандт

1

проверьте, что вы не ждете разрешения DNS где-то.


0

+ Изменить

ssl_protocols  SSLv2 SSLv3 TLSv1;

в

ssl_protocols  SSLv3 TLSv1 SSLv2;

Пытается протоколы в том порядке, в котором они перечислены.


Не очень помогло. См. Webpagetest.org/result/101020_8KVR/1/details - переговоры все еще занимают> 50% всего времени.
Парас Чопра

2
SSLv2 НЕ должен использоваться, это небезопасно. На момент написания этого комментария все основные браузеры должны поддерживать TLSv1, поэтому больше не требуется SSLv3. (в идеале это должен быть TLSv1 TLSv1.1 TLSv1.2, пока большинство браузеров не примут 1.1).
KBeezie
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.