Техническое: настройки TLS/SSL и сопутствующих параметров на dxdt.ru
Поделюсь настройками TLS на веб-сервере dxdt.ru. Я использую связку Apache+mod_ssl (стандартное решение). Важнейшие параметры – это используемые протоколы, “шифронаборы” (Cipher Suites – часто переводят как “наборы шифров”), а также их приоритет. Например, сейчас не рекомендуется использовать SSLv3 (и более ранние версии, которые, конечно, экзотика, но всё ещё встречаются в “живой природе”). Соответственно, в ssl.conf (файл конфигурации mod_ssl) для хоста dxdt.ru указаны следующие строки:
SSLProtocol -ALL +TLSv1 +TLSv1.1 +TLSv1.2
SSLHonorCipherOrder on
SSLCipherSuite “EECDH+AESGCM EDH+AESGCM EECDH+AES EDH+aRSA !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4”
Первая директива (SSLProtocol) разрешает только TLS (в трёх версиях, как несложно догадаться). Протоколы семейства SSL – не поддерживаем. Вторая директива (SSLHonorCipherOrder) указывает, что mod_ssl должен использовать приоритеты наборов шифров, заданные сервером (а не клиентом, то есть браузеру не удастся навязать свои предпочтения).
Директива SSLCipherSuite – это самое сложное место в настройках. Она определяет допустимые криптографические наборы (“шифронаборы”: алгоритмы обмена ключами и аутентификации, шифр, режим шифрования, алгоритм дайджеста). Условные имена наборов разделены пробелами. Конкретный набор согласуется клиентом и сервером во время установления соединения. Если договориться о подходящем наборе не удалось – TLS-соединение не устанавливается (именно это и происходит в случае IE8 под Windows XP).
В mod_ssl используются сокращённые имена для обозначения групп шифронаборов. Например: EECDH+AESGCM означает, что для генерации сеансового ключа будет использоваться алгоритм Ephemeral elliptic-curve Diffie-Hellman (разновидность алгоритма Диффи-Хеллмана на эллиптических кривых), а в роли алгоритма шифрования выступит AES в режиме GCM (Galois/Counter Mode – Режим счётчика с “аутентификацией Галуа”: один из современных “продвинутых” режимов блочных шифров, обеспечивающий, в том числе, аутентификацию данных; Галуа там возникает потому, что алгоритм аутентификации работает в конечном поле).
Сайт dxdt.ru использует серверный сертификат с ключом RSA; соответственно, аутентификацию сеансовых ключей можно проводить только при помощи криптосистемы RSA. Это некоторым образом экономит нам пространство в конфигурационной строке mod_ssl: вовсе не обязательно вписывать туда подробные указания вроде EECDH+ECDSA+AESGCM, как нередко рекомендуют, – DSA всё равно не поддерживается.
Несложно догадаться, что подстроки в SSLCipherSuite, начинающиеся с ‘!’, обозначают запрет на использование определённых криптосистем или криптографических примитивов. Всегда полезно прямо запретить заведомо неподходящие алгоритмы. Отмечу, что, в соответствии с современными традициями, запрещён RC4 (хотя он всё равно не предлагался бы сервером с указанными шифронаборами – не подходит).
Update (23/12/2014): в комментариях подсказали изящный вариант, с отключением всего ненужного одной директивой -ALL в SSLCipherSuite; такой вариант требует более точного описания шифронаборов, но зато он лаконичен:
SSLCipherSuite “-ALL:EECDH+aRSA+AESGCM:EDH+aRSA+AESGCM:EECDH+aRSA+AES:EDH+aRSA+AES”
(Обратите внимание, что пробелы заменены на двоеточия.)
В HTTP-ответ добавлено поле HSTS (HTTP Strict Transport Security – требование “принудительной безопасности” для HTTP):
Header add Strict-Transport-Security “max-age=15552000”
Данное поле означает, что, грубо говоря, браузер должен запомнить, что к данному сайту доступ необходимо осуществлять только по HTTPS, в течение времени, указанного в параметре max-age поля HSTS. Это позволяет защититься от множества атак, основанных на подмене протокола HTTPS на HTTP.
Вот. Так работает TLS на dxdt.ru.
Адрес записки: https://dxdt.ru/2014/12/20/7160/
Похожие записки:
- Архитектура микропроцессоров и изоляция уровней исполнения
- Техническое: Google Public DNS и DNSSEC
- Обновление "Избранных записок"
- Ретроспектива заметок: декабрь 2012 года
- Техническое: экзотические настройки в SPF
- Наложенные сети Google и браузеры в будущем
- Техническое: ECDSA на кривой Curve25519 в GNS
- Заметки за июль 2024
- Правила пакетной фильтрации и "постквантовое" ClientHello
- Год 2024, новый
- Записки за август 2023
Комментарии читателей блога: 6
1. 20th December 2014, 22:14 // Читатель Dmitry Belyavsky написал:
Я не очень понимаю, зачем тебе отрубать одновременно 3DES и RC4. То есть понимаю, но тем самым ты хоронишь старые браузеры. Их, правда, не дофига.
2. 21st December 2014, 07:47 // Александр Венедюхин:
Собственно, старые браузеры и пора хоронить.
3. 22nd December 2014, 01:59 // Читатель Z.T. написал:
@Александр Венедюхин
А почему не начать SSLCipherSuite с -ALL? CAMELLIA и SEED не нужны, и будет короче и проще.
@Dmitry Belyavsky
Да, весь смысл не подерживать SChannel от Windows XP. Если бы Apple поддерживала AES GCM а дешевые аппараты Android обновлялись хотябы до версии 4.4, можно и нужно было бы не поддерживать MAC-then-Encrypt AES CBC.
А когда будет поддежка ключей ed25519, можно будет упразднить поддержку PKCS#1 v1.5 RSA.
4. 22nd December 2014, 23:24 // Александр Венедюхин:
> А почему не начать SSLCipherSuite с -ALL?
Можно, наверное, но тогда придётся ж расписать все подстановки более детально – иначе у меня mod_ssl отказывается стартовать.
5. 23rd December 2014, 00:36 // Читатель Z.T. написал:
$ diff -u <(openssl ciphers -v 'EECDH+AESGCM EDH+AESGCM EECDH+AES EDH+aRSA !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4') <(openssl ciphers -v '-ALL:EECDH+aRSA+AESGCM:EDH+aRSA+AESGCM:EECDH+aRSA+AES:EDH+aRSA+AES')
— /dev/fd/63 2014-12-22 23:31:58.286494365 +0200
+++ /dev/fd/62 2014-12-22 23:31:58.294494365 +0200
@@ -1,21 +1,12 @@
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
-ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
-ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
-ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384
ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1
-ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256
-ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256
ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
-ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
-DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1
DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
-DHE-RSA-SEED-SHA SSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1
-DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1
и тогда
openssl s_client -connect localhost:443 -servername xubuntu -CAfile /etc/ssl/certs/ssl-cert-snakeoil.pem -cipher DHE-RSA-AES128-SHA
работает
а вот
openssl s_client -connect localhost:443 -servername xubuntu -CAfile /etc/ssl/certs/ssl-cert-snakeoil.pem -cipher DHE-RSA-CAMELLIA128-SHA
не работает.
6. 23rd December 2014, 10:17 // Александр Венедюхин:
> $ diff -u
Хм, да, согласен, этот вариант оптимален и логичен. Переделал. Спасибо!