3 заметки с тегом

HPKP

Глюк Firefox и Thunderbird

Уже не в первый раз сталкиваюсь со странным поведение браузера от Mozilla. Сайт имеет ключи HPKP и указан HSTS, хэши для нового сертификата сгенерированы заново и указаны в файле конфигурации. То есть, по логике, все должно работать. Но увы... При этом все остальные браузеры нормально открывают сайт.
Точно также ведет себя и Thunderbird — просто отказывается подключаться к dovecot по тому же адресу, чтобы принять почту. В логах для обоих высвечивается одна и та же ошибка. Поиск в интернете выдает, что ошибка очень частая, но решений, кроме использования самоподписанных сертификатов, по видимому, нет. А мне лично этого не хотелось бы делать — зачем тогда в системе установлен робот, который следит за актуальностью сертификатов и, при необходимости, обновляет их.
В прошлый раз я обошелся тем, что использовал для этого конкретного сайта созданный ранее сертификат, но его срок действия заканчивается через несколько дней и использовать его дальше бессмысленно. В этот раз даже пока что в голову не приходит что делать. Надо пошевелить мозгами.

Связка nginx+Apache

Немного почитав про эту связку, пришел к выводу, что стоит попробовать ее использовать. Установил nginx, перенастроил Apache таким образом, чтобы он работал только локально, затем настроил nginx таким образом, чтобы он все запросы отдавал Apache. Потом еще некоторое время пришлось повозиться с настройками nginx, но вуаля! Я добился-таки того, что все сайты, на которых я проводил тестирование своего сервера, выдали мне оценку «А+». Итак, что из «плюсов» мы имеем:

  • — возросла скорость загрузки сайта;
  • — уменьшилась нагрузка на Apache;
  • — статические данные теперь отдает nginx, динамические — формирует Apache;
  • — остались все «плюшки» .htaccess;
  • — возросла безопасность сервера.

Из «минусов»:

  • — теперь на сервере у меня два веб-сервера.

Чуть позже попробую конфигурацию с «голым» nginx, если его работа меня устроит, то, скорее всего, полностью перейду на него. Теперь что касается безопасности сервера (ну да, у меня маленький бзик на этот счет).

В связи с тем, что nginx, в отличие от Apache, поддерживает наборы шифрования ECDHE, появилась возможность их использовать. Также он поддерживает OCSP stapling, что позволяет немного ускорить загрузку страниц при работе через HTTPS.

Тестирование проводилось при помощи трех сайтов: SSL Analyzer от Comodo, Free SSL Server Test от High-Tech Bridge, ну и конечно незабвенный SSL Server Test от лаборатории Qualys SSL.

Первый ресурс позволяет провести быстрый тест наборов шифров и некоторых других параметров, он является самым быстрым из этих трех серверов. Удовлетворить его требования оказалось самым простым.

Затем тест проводился при помощи High-Tech Bridge. По скорость он является более медленным, но проверяет чуть больше параметров. В том числе на соответствие требованиям NIST (американский институт стандартов и технологий) и стандарта PCI DSS. Здесь пришлось немного попотеть, разыскивая наборы шифрования, которые, по его мнению, должны быть включены в список.

И под конец проверка шла при помощи Qualys SSL. Он является самым медленным из указанного списка, но выдает результаты практически по всем параметрам. Здесь пришлось поработать над несколькими пунктами, но и тут была одержана победа.

Если какие-то условия не удовлетворяли хотя бы один сайт, параметры редактировались и проверка начиналась заново. В итоге, все требования соблюдены:

  • — сервер работает только по протоколу TLS;
  • — слабые шифры удалены из списка;
  • — Perfect Forward Secrecy (PFS) работает со всеми более-менее новыми браузерами;
  • — поддерживаются HSTS и HPKP;
  • — поддерживается OCSP stapling;
  • — работает Content Security Policy;
  • — работает вся ранее настроенная в Apache защита от атак.

В общем все круто и я всем доволен :-) Кроме, разве что того момента, что теперь в этом плане мне делать нечего и скоро я опять начну скучать.

Защита сайта при помощи HTTP Public Key Pinning (HPKP)

Данная технология призвана защитить посетителя вашего сайта от атаки типа MITM (Man in the middle, человек посередине). Иными словами посетитель может быть уверен, что данные, которые он получает, исходят с вашего сайта, а не с какого-то другого.

Суть технологии состоит в создании публичного ключа на основе сертификата, который установлен на вашем сайте. Соответственно, чтобы она работала, требуется валидный сертификат. Впрочем, она будет работать и на самоподписанных (self-signed) сертификатах. Полученный на основе вашего сертификата ключ добавляется в заголовок ответа вашего сервера, после чего браузер сравнивает полученный ключ с тем, который он вычисляет после получения данных о вашем сертификате.

Итак, что нам требуется:

  1. Какой-либо установленный для сайта сертификат.
  2. Консоль для получения публичного ключа.

Кстати, не так давно для нормального функционирования этой технологии требовался всего лишь один ключ, сейчас же нужно указывать два или более ключей. На мой взгляд двух будет достаточно, от этого и будем отталкиваться. Второй ключ является «резервным», этот момент я не совсем понимаю, но не будем отступать от требований.

Действовал я по следующей схеме:

  • — получаем сертификат на сайте Let’s Encrypt для двух сайтов: example.com и www.example.com;
  • — так как я использую вариант без www, то ключ, полученный на базе первого будет основным, на базе второго — резервным;
  • — генерируем ключи для обоих сертификатов;
  • — добавляем нужные инструкции в файл /etc/httpd2/conf/sites-available/default-http.conf.

О получении сертификата рассказывать не буду, достаточно почитать главную страницу сайта. Допустим, вы его получили и установили на свой сайт. Теперь требуется создать ключи при помощи следующей команды:

openssl x509 -noout -in certificate.pem -pubkey | openssl rsa -pubin -outform der | \
openssl dgst -sha256 -binary | base64

где certificate.pem — полный путь к сертфикату.

После выполнения команды вы получите нечто подобное:

LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=

Это и есть нужный вам ключ. Повторяем команду для второго сертификата и добавляем данные в файл конфигурации сайта:

Header set Public-Key-Pins "pin-sha256=\"pin1\"; pin-sha256=\"pin2\"; max-age=time"

где:

  • pin1 — основной ключ для данного сайта. В моем случае example.com;
  • pin2 — резервный ключ для сайта. То есть www.example.com;
  • time — время действия ключа в секундах.

Опциональный параметр includeSubDomains указывает на то, что ключи действительны также для поддоменов. Еще один необязательный параметр report-uri указывает на адрес, куда должны отправляться отчеты об ошибках в формате JSON. Его я, возможно, добавлю на сайт, но пока что считаю его ненужным для себя.

Какие тут есть нюансы? Если вы неправильно настроите HPKP, ваш сайт станет недоступен. Можно также настроить отправку отчетов в случае каких-либо ошибок. Для этого немного меняем заголовок (или просто добавляем еще одной строкой):

Header set Public-Key-Pins-Report-Only "pin-sha256=\"pin1\"; pin-sha256=\"pin2\"; max-age=time"