dxdt.blog: занимательный интернет-журнал

Поделюсь настройками 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.

На страницах dxdt.ru немало заметок про РЛС. Правда, сейчас новые заметки на эту тему появляются всё реже. Нужно будет попытаться исправить ситуацию. А пока что – небольшая подборка из опубликованного:

• Интеллектуальные помехи комплексам ПВО;
• “Малозаметные” радары – преимущество приёмника;
• Сигнатуры, ПВО и утечки информации по побочным каналам;
• Радиолокация и уязвимости DNS;
• Бистатическая радиолокация против астероидов.

В текущей конфигурации полезный сервис Qualys SSL Labs присваивает dxdt.ru высшую оценку A (Grade A – update: уже Grade A+, так как добавлен заголовок HSTS):

То есть, TLS на сервере настроен современным образом. Например, для всех распространённых браузеров поддерживается “прогрессивная секретность“. Этот момент, вкупе с настройкой наборов шифров на сервере, приводит к тому, что сайт недоступен для браузеров IE7 и IE8, работающих под Windows XP – они не поддерживают нужных наборов шифров и, соответственно, не смогут договориться с сервером. Но это настолько устаревшая конфигурация, что за неё можно не беспокоиться. (Под Windows XP, если вдруг эта устаревшая система оказалась на персональном компьютере в 2014 году, обычно используют другие браузеры, а с ними проблем быть не должно.)

Update: добавил заголовок HSTS (HTTP Strict Transport Security – предписывает браузерам использовать только HTTPS для данного сайта), теперь оценка A+.

Примерно две недели назад я полностью заменил для dxdt.ru протокол доставки веб-страниц на HTTPS. Самое время поделиться первыми впечатлениями. Во-первых, объём пользовательского трафика (посещений страниц) не изменился – не вырос, но и не упал. Мне предсказывали небольшое падение трафика за счёт изменений в индексах поисковых машин. Этого не заметно (насколько вообще что-то можно заметить в том весьма скромном трафике с поисковиков, который есть на dxdt.ru).

Во-вторых, нагрузка на сервер выросла, Apache ест несколько больше памяти, но виртуальная машина из Amazon EC2, как и прежде, вполне себе справляется. То есть, тут проблем нет. Однако время загрузки веб-страниц увеличилось, хотя и осталось в разумных пределах (менее секунды). Виной здесь не столько переход на HTTPS, сколько то, что в результате этого перехода поломался полезный плагин для WordPress: W3 Total Cache. Этот плагин заметно сокращал время генерации страниц CMS, за счёт кэширования (в Memcached). После замены протокола, кэш на сайте перестал автоматически сбрасываться при добавлении новых заметок, приходилось передёргивать его руками. В деталях я пока с этим явлением не разбирался, а просто удалил плагин, что, собственно, и привело к замедлению работы сайта.

В-третьих, с SSL-сертификатом COMODO, выпущенным от корня AddTrust CA через пару промежуточных сертификатов, возникли некоторые проблемы. По неясной мне причине, браузер Safari под Mac OS на некоторых “макбуках” данному сертификату доверять отказывается: в списке доверенных корней этой линейки браузеров нет подходящего корня (AddTrust или чего-нибудь иного, но с тем же ключом, да). Я уверен, что на сервере у меня всё правильно настроено: отдаются и серверный, и необходимые промежуточные сертификаты. Что происходит с некоторыми образцами программно-аппаратных продуктов компании Apple – ещё предстоит разобраться (у меня нет “макбука” – значит, для тестов мне нужно его у кого-то отобрать, да ещё и в подходящей комплектации). Замену SSL-сертификата, тем не менее, пока не планирую.

Небольшая подборка записок по теме TLS/SSL (и близким к ней), появлявшихся на dxdt.ru:

• HTTPS и “открытые веб-страницы”;
• Heartbleed, OpenSSL: работа над ошибками;
• Система прослушивания TLS/SSL от NSA. Часть 1;
• Система прослушивания TLS/SSL от NSA. Часть 2;
• Популярно о перехвате HTTPS;
• Цифровые нотариаты и административное значение TLS/SSL;
• Политика браузеров и история с SSL/TLS;
• Технология DANE: отличия от работы УЦ;
• Новинки безопасности, практикум: настройка DANE и dane.nox.su.

Собственно, добавил в зону dxdt.ru TLSA-запись, содержание которой соответствует отпечатку (SHA-256) серверного сертификата – это означает, что для dxdt.ru теперь заработала поддержка DANE (технологии, позволяющей с помощью DNSSEC защитить домен от подмены SSL-сертификата). Вот бы ещё DANE, наконец-то, стали поддерживать браузеры.

После того, как я перевёл dxdt.ru на HTTPS, можно сказать, что на сайте используются обе современные ключевые интернетовские технологии обеспечения безопасности. Вторая – это DNSSEC: домен dxdt.ru подписан с декабря 2012 года (пора, наверное, поменять ключи). Для полноты картины осталось добавить запись DANE TLSA, как это сделано на тестовом сервере 1d.pw.

(Кстати, предлагали сразу добавить SPDY – это разработанный с подачи и при ключевом участии Google перспективный протокол, оптимизирующий загрузку веб-страниц через TLS-соединение. На мой взгляд, хоть SPDY и поддерживают современные браузеры, но это всё ещё экзотика, не хуже DANE или даже DNSSEC, так что можно подождать HTTP/2.)

Сделал HTTPS основным протоколом на dxdt.ru. Теперь, при обращении по HTTP, сервер отвечает редиректом (301) на соответствующий URL с HTTPS.

Каких-то проблем тотальная замена протокола не вызвала, что удивительно. Пришлось, впрочем, поправить все ссылки в базе WordPress-а: эта CMS генерирует абсолютные ссылки с указанием протокола (было – http://) и пишет их в БД. Задача решалась в лоб: выгрузкой дампа базы и заменой силами Perl-а http на https в подходящих местах, с последующей загрузкой дампа обратно; так что, в принципе, могут быть некоторые накладки (но пока что обнаружить их не удалось).

Сейчас никаких предупреждений о “небезопасном содержимом” быть не должно, всё работает только по HTTPS. Если обнаружите ошибки и дефекты – просьба сообщить в комментариях к этой заметке или по электронной почте.

(Основная стратегическая трудность – нагрузка на сервер: HTTPS увеличивает её в разы, но, надеюсь, скромных ресурсов хватит.)

Пробую постепенно переводить dxdt.ru на HTTPS, в качестве основного протокола. Получил и уже установил на сервер SSL-сертификат от хорошо известного (браузерам) удостоверяющего центра COMODO. Раньше использовался сертификат, выпущенный моим собственным УЦ, который, естественно, в стандартный браузерный набор корней не входит. Поэтому, при обращении по HTTPS, можно было наблюдать предупреждение системы безопасности (если только корень моего УЦ не был импортирован в браузер). Сейчас такого предупреждения быть уже не должно: https://dxdt.ru/.

Осталось поправить ссылки на элементы страниц: разные картинки и, например, файлы CSS, загружаются по HTTP, потому что так указано в коде. Соответственно, сейчас страницы dxdt.ru, загруженные по HTTPS, содержат “небезопасные” элементы. Но это исправимо. Следующий этап: безусловный редирект с HTTP на HTTPS, то есть, по HTTP страницы передаваться не будут.

Очередной раз обновил список избранных записок dxdt.ru.

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

• Базы авиаперелётов и идентификация смартфонов (2014)
• Эволюция телефонного аппарата как персонального жучка
• Смартфоны, QR-коды и точная геолокация (2012)
• Персональные данные, которые расползаются (2011)
• Обнаружение “анонимных” мобильных телефонов (2010)
• GPS наоборот или определение координат мобильника (2009)
• Поисковая сеть из мобильных телефонов (2008)