На прошлой неделе я переключил загруженный сайт на TLS-везде и HTTP / 2. Производительность не улучшилась так сильно, как хотелось бы. Фактически, в зависимости от того, как вы его измеряете, вы можете утверждать, что он ухудшился.
Существует множество возможностей для дальнейшей оптимизации сервера, на уровне ОС TCP-настройки, TLS-конфигурация в веб-стеке и т. Д. Чтобы убедиться, что я не упускаю никаких моментов для улучшения, я публикую здесь свои мысли, чтобы другие могли перезвонить в.
В настоящее время конфигурация SSL выглядит так. Различные стороны контролируют различные элементы этого, у меня нет прямого контроля над всем этим. Доменное имя подверглось цензуре.
$ openssl s_client -state -CAfile Documents/Thawte\ Server\ CA.cer -connect xxxxxx.tld:443
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=3 /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
verify error:num=19:self signed certificate in certificate chain
verify return:0
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server key exchange A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read finished A
---
Certificate chain
0 s:/C=xxx
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA
1 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
3 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIF1----shZZU
y1kFXCCRo78=
-----END CERTIFICATE-----
subject=/C=xxx
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA
---
No client certificate CA names sent
---
SSL handshake has read 6240 bytes and written 328 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES128-SHA
Session-ID: 09464B1CF8972B08267C33BF255FDA74216728E3599B24EAE02B13642C268483
Session-ID-ctx:
Master-Key: ACC3529AC7C80162797397D4E3041D1720EE4BA6A8BA5D2C200F8B48ADD6960CA9E48D5FF975472A9E8B43B7023CA4E4
Key-Arg : None
Start Time: 1457708322
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
SSL3 alert read:warning:close notify
closed
SSL3 alert write:warning:close notify
Проблемы, которые я вижу:
ошибка проверки: число = 19: самоподписанный сертификат в цепочке сертификатов
Я хочу, чтобы цепочка была как можно короче, в правильном порядке (это не соответствует ssllabs.com), и в цепочке не должно быть необходимости в самозаверяющих сертификатах. Изменить: я вижу, что на самом деле это корневой сертификат CA, который уже находится в хранилище доверенных сертификатов браузера. Это все равно нужно удалить.
SSL_connect: SSLv3 чтение сертификата сервера A SSL_connect: SSLv3 обмен ключами сервера чтения SSL_connect: SSLv3 чтение сервера выполнено A SSL_connect: SSLv3 запись клиентского ключа обмена SSL_connect: спецификация шифра изменения записи SSLv3 A SSL_connect: запись SSLv3 завершена A SSL_connect: SSLv3 flush data SSL_connect : SSLv3 чтение завершено A
Эта последовательность рукопожатий кажется мне длинной. На других конфигурациях я видел меньше перебранок. Мое желание - свести число поездок туда и обратно к минимуму.
Цепочка сертификатов 0,1,2,3 - состоит из 4 (Comodo) сертификатов, она превышает 5,5 КБ и, следовательно, может не соответствовать размеру окна перегрузки TCP (еще не проверено). Наверное, причина лишних поездок туда и обратно (?).
Возможно, стоит перейти на центр сертификации, предлагающий более короткие цепочки. Какие-либо предложения?
Шифр: DHE-RSA-AES128-SHA
Слабый шифр Диффи Хелмана. SSLLabs добавляет: «Использует обычные простые числа DH. Да, если возможно, заменить их пользовательскими параметрами».
Отсюда мои вопросы:
Мы будем очень признательны за ваше понимание.
Давайте сначала отсортируем цепочку сертификатов. Это должно позаботиться о первых 4 точках.
Вам будет отправлен сертификат от Comodo, и вам также понадобится еще несколько сертификатов. Список сертификатов можно найти Вот. Вам нужно будет проверить сертификат, чтобы узнать, с каким ЦС он был подписан.
После того, как вы определили CA, загрузите пакет и поместите его в тот же каталог, что и сертификат, который вам был отправлен. Затем вам нужно будет объединить их, используя следующую команду
cat name_of_file_you_were_sent name_of_bundle_file > www.example.com.crt
Вы можете заметить, что последний CA "отсутствует" в комплекте, это не помешает вам пройти эту часть теста на ssllabs.
Затем вам нужно будет указать этот файл вместе с файлом закрытого ключа в конфигурации nginx (что вы, очевидно, сделали, но для полноты), используя эти две строки конфигурации
ssl_certificate www.example.com.crt;
ssl_certificate_key www.example.com.key;
Протестируйте конфигурацию nginx и перезапустите, если все в порядке
Что касается остальной комплектации.
Лучший сайт, который я нашел для создания конфигурации SSL для nginx, - это Mozilla Security Я не включил пример, так как их много только на serverfault
В зависимости от трафика вашего сайта вы захотите использовать промежуточный или современный (надеюсь, вам не нужно использовать старые, и если вы хотите, вы можете решить это, но это другой вопрос)
Вы не должны просто копировать и вставлять эти конфигурации, не понимая, что будут делать настройки. HSTS, например, может иметь долгосрочное влияние на посетителей сайта.
Хотя в целом эта конфигурация «безопасна», ее можно еще немного оптимизировать. В частности
ssl_buffer_size 16k; #Better if you have video
ssl_buffer_size 4k; #Better for quicker first byte.
Конечно, могут быть и другие причины, по которым переход на http / 2 не повысил производительность вашего сайта.
Например, http / 2 открывает намного больше соединений с сервером. Вы учли это и скорректировали worker_processes и worker_connections но вышеприведенное касается всего, что напрямую связано с частями конфигурации SSL в nginx.