Содержание
В ближайшие несколько лет технология привязывания ключей (key pinning) будет главной надеждой в системе безопасности протокола TLS, делая целевые атаки, связанные с Центрами Сертификации, намного более рискованными.
В ближайшие несколько лет технология привязывания ключей (key pinning) будет главной надеждой в системе безопасности протокола TLS, делая целевые атаки, связанные с Центрами Сертификации, намного более рискованными. Пока мы ждем появления новых систем с встроенным привязыванием ключей, уже сейчас можно воспользоваться технологией HTTP Public Key Pinning (HPKP), позволяющей выполнять привязывание ключей «на коленке».
Главный компонент в протоколе шифрования – идентификация оппонента, а вовсе не сам алгоритм. Даже самое стойкое шифрование бесполезно, если вы общаетесь не с тем, с кем намеревались. В протоколах SSL/TLS идентификация реализована на базе цепочки сертификатов, представляющих собой серию сертификатов стандарта X.509 с публичными ключами. Ваш браузер доверяет набору корневых сертификатов, принадлежащих Центрам Сертификации. Эти центры в свою очередь передают сертификаты веб-сайтам, которые вы посещаете. Когда, например, вы заходите на сайт rlove.org, ваш браузер проверяет цепочку сертификатов, начиная с того, которым владеет сайт rlove.org и далее по цепочке до корневого сертификата. Если ваш браузер доверяет корневому сертификату, вы точно знаете, что общаетесь со мной, а не со злоумышленником.
Главная проблема в вышеописанной системе заключается в том, что в случае подделки корневого сертификата компрометируется вся модель идентификации. Если, к примеру, я украду секретный ключ какого-либо центра, которому доверяет ваш браузер, я смогу создавать валидные сертификаты для любого веб-сайта. Можно пойти еще дальше и реализовать глобальную MITM-атаку против каждого веб-сайта, который посещает пользователь, находящийся со мной в одной сети. Подобное периодически случается.
Идеальная защита от MITM-атак – предварительный обмен ключами. В этой статье я расскажу о технологии, которая также поможет значительно снизить риск MITM-атаки. Суть механизма заключается в ограничении сертификатов, используемых в цепочке на стороне сайта. Кроме того, эта технология позволяет детектировать атаки прямо во время их осуществления.
Привязывание публичных ключей
Технология HTTP Public Key Pinning (HPKP) является наброском IETF-стандарта, реализующего механизм прикрепления публичных ключей через HTTP-заголовок, который заставляет браузеры затребовать сертификат из белого списка для всех последующих соединений с конкретным веб-сайтом. Этот метод серьезно сокращает вероятность осуществления успешной MITM-атаки. Вместо любого корневого сертификата, мы запрашиваем конкретный корневой и промежуточный сертификат или даже точный публичный ключ.
Заголовок, используемый в технологии HPKP, выглядит так:
Public-Key-Pins: pin-sha256="XXX"; pin-sha256="YYY"; max-age=ZZZ
где XXX – SHA256-хеш публичного ключа, закодированный в base64, для сертификата из белого списка; YYY – резервная копия того же самого ключа; ZZZ – время жизни (в секундах) для белого списка. Заголовок также может содержать директиву includeSubdomains, предписывающую браузерам применять белый список ко всем хостам данного домена. Директива report-uri предписывает браузерам отправлять отчеты о проверках привязки, завершившихся неудачно.
Вы можете указать столько директив pin-sha256, сколько захотите. В цепочке сертификатов должна быть только одна сигнатура (fingerprint). Кроме того, необходимо указать как минимум одну сигнатуру, которая не входит в текущую цепочку. Другими словами, стандарт предписывает иметь резервную копию привязанного ключа.
Наилучший вариант – привязывать ваш собственный публичный ключ. Однако здесь потребуется уделить особое внимание управлению копиями ключей, что может вызвать затруднения, если вы часто меняете сертификаты. Более простой, но менее безопасный способ – привязать первый промежуточный сертификат из цепочки, то есть один из сертификатов вашего сайта. Это позволит упростить процесс управления вашими сертификатами и в то же время защитит от MITM-атаки.
Генерирование SPKI Fingerprint
Технология HPKP требует SHA256-хеш публичного ключа, закодированный в base64, который вы хотите привязать. Вы можете легко получить ключ либо при помощи запроса на получение сертификата (certificate signing request; CSR), либо из сертификата на базе стандарта X.509. Вам нужен только один ключ.
Генерируем содержимое для директивы pin-sha256 на базе публичного ключа (pub.key):
openssl rsa -pubout -in pub.key -outform der |
openssl dgst -sha256 -binary |
base64
Генерируем на базе CSR (my.csr):
openssl req -noout -in my.csr -pubkey |
openssl rsa -pubin -outform der |
openssl dgst -sha256 -binary |
base64
Генерируем на базе сертификата, закодированного в формате PEM (certificate.pem):
openssl x509 -noout -in certificate.pem -pubkey |
openssl rsa -pubin -outform der |
openssl dgst -sha256 -binary |
base64
После выполнения команд, показанных выше, получите нечто подобное:
Эту строку необходимо добавить в директиву pin-sha256. Вы можете повторить этот процесс для каждого ключа, который хотите привязать. Например, если у вас есть два сертификата для сайта, можете привязать оба. Как было сказано выше, вам нужна отдельная директива pin-sha256 с резервным ключом.
Поскольку неправильно сконфигурированный HPKP-заголовок может сделать ваш сайт недоступным, выкатывать обновления следует с осторожностью. Несколько советов:
Установите значение параметра max-age в несколько минут и постепенно увеличивайте до тех пор, пока не добьетесь удовлетворительных результатов.
Используйте заголовок Public-Key-Pins-Report-Only для генерации и отправки отчетов о неудачах на адрес, содержащийся в параметре report-uri, без принудительного привязывания.
Пробуйте различные привязки от разных Центров Сертификации.
При использовании технологии HPKP не требуется специальной поддержки HTTP-сервера; нужно лишь добавить новый заголовок. Настройка для Apache:
Header set Public-Key-Pins "pin-sha256="XXX"; pin-sha256="YYY"; max-age=ZZZ"
Настройка для Nginx:
add_header Public-Key-Pins ‘pin-sha256="XXX"; pin-sha256="YYY"; max-age=ZZZ’;
Более общую информацию о конфигурировании протоколов SSL/TLS для Apache и Nginx можно почерпнуть в других моих статьях (ссылка 1, ссылка 2).
Верификация привязанных ключей
Верификация является нетривиальной задачей, поскольку проект стандарта требует успешной проверки ключа перед запоминанием привязанной сигнатуры. Таким образом, вы не можете работать с непонятной сигнатурой для верификации неудачи при привязывании ключа. Успешное подключение к веб-серверу также не означает, что привязывание запомнилось. Простейший способ проверки — при помощи команды chrome://net-internals/#hsts. В разделе Query domain введите адрес вашего сайта и проверьте, что сигнатуры ключей отображаются в списке под строкой dynamic_spki_hashes. Браузер Chrome будет хранить сигнатуры только в случае успешной верификации.
Отчет о неудачных проверках
В спецификации заложен механизм отправки отчетов при неудачной проверке ключа. Отчеты отправляются по адресу, указанному в директиве report-uri. Эта возможность полезна не только на этапе отладки, но и при детектировании MITM-атак против ваших пользователей. На самом деле, только само присутствие этой возможности делает технологию Public Key Pinning устойчивой к MITM-атакам.
Отчеты отправляются через HTTP POST следующего JSON-сообщения:
<
"date-time": date-time,
"hostname": hostname,
"port": port,
"effective-expiration-date": expiration-date,
"include-subdomains": include-subdomains,
"noted-hostname": noted-hostname,
"served-certificate-chain": [
pem1, . pemN
],
"validated-certificate-chain": [
pem1, . pemN
],
"known-pins": [
known-pin1, . known-pinN
]
>
Технология HPKP поддерживается браузерами Chrome 38, Firefox 35 (и более поздних версиях).
Хотя у технологии HPKP есть несколько недостатков, в целом я рекомендую ее к использованию. Самая главная уязвимость заключается в том, что HPKP – это механизм вида trust-on-first-use (доверие при первом использовании). Иными словами, пользователь не сможет узнать о MITM-атаке при первом подключении к сайту. С другой стороны, для повторной MITM-атаки злоумышленнику нужно перехватить все соединения к веб-сайту. Учитывая характер сегодняшних угроз, технология HPKP является вполне приемлемой защитой. Примечательно, что злоумышленник перед тем, как осуществить MITM-атаку, обязан знать, хранятся ли на целевой машине привязанные ключи. Иначе в браузере пользователя появится грозное предупреждение (и, возможно, отправится отчет администратору сайта) об ошибке при верификации.
Подписывайтесь на каналы "SecurityLab" в 
Telegram и 
Яндекс.Дзен, чтобы первыми узнавать о новостях и эксклюзивных материалах по информационной безопасности.
Думаю большинство из вас сталкивается с этой проблемой ведя разработку на локальном сервере. Я же столкнулся с этим работая с vagrant. Просто однажды перестали открываться вообще все сайты над которыми я когда-либо работал веду работу. Проверив работает ли в браузере Vivaldi (работает на движке хромиум, как и хром) я обнаружил, что сайты там работают. Списал все на глюк мазилы, но дело оказалось в другом..
За неделю я очень устал работать через вивальди, т.к. лично для меня инспектор кода хромиума (стандартный в вивальди, хроме, опере и тд) совсем неудобный, если сравнивать с мазиловским. Решил разобраться в проблеме, перезагрузка компа не помогла, в интернете одни и те же рерайченные статьи о том, как в мазиле надо удалить базу сертификатов, или внести свой вручную, или нажать на кнопку "дополнительно -> исключения" (которой, к слову, у меня не было).
Проблему решить так и не удалось никаким способом, проверив работу сайтов в опере, я, к удивлению, обнаружил, что там та же самая проблема: сайты не открываются. В чем же дело? Начал долго и упорно искать информацию. и не безуспешно.
Что такое Форсированное защищённое соединение HTTP (HSTS) ?
Говоря просто, это когда сайт должен открываться по протоколу http, а он открывается по https, при этом никаких редиректов никто не делал. Так в чем проблема?
Оказалось, что недавно мазила и хром (странно, почему сайты в вивальди работают — тот же хром, только с другим оформлением), приняли такое решение: все сайты, у которых домены: .dev и .foo насильно редиректятся на https. Зачем это надо было делать — я не знаю, да и читать желания никакого нет.
От себя хочу добавить, что домен .app так же редиректит на https.
Как избавиться от формированного защищенного соединения HSTS?
Очень просто — придется менять все домены на какие-либо другие. Разработчики рекомендуют переключаться на домен .test, мне, например, такое не по душе, и я уже привык писать во всех своих проектах .dev, поэтому решил для себя выбрать в качестве нового домена: .dem. И действительно, теперь сайты прекрасно работают во всех браузерах.
Вот так нам любят попортить жизнь своими нововведениями. Сначала сами советуют использовать для локалок .dev, а затем принимают такую вот фигню.
Делитесь этой статьей с друзьями и коллегами, потому что найти в рунете информацию по данному вопросу совершенно нереально. Поможем вместе решить проблему с соединением HTTP (HSTS)!
Про HSTS на Хабре уже писали, этот механизм включен в генераторе конфигов для веб-серверов от Mozilla. Написать этот пост я решил за один день столкнувшись с недоступность сразу двух крупных сайтов из-за HSTS.
Что такое HSTS?
HSTS (HTTP Strict Transport Security) — это механизм защиты от даунгрейд-атак на TLS, указывающий браузеру всегда использовать TLS для сайтов с соответствующими политиками. Стандарт описан в RFC6797, а политики бывают двух видов:
Динамические
Политика применяется из HTTP-заголовка Strict-Transport-Security при первом заходе на сайт по HTTPS, в нём указан срок действия и применимость к субдоменам:
Статические
Статические политики захардкожены в браузер и для некоторых сайтов включает привязку к вышестоящему CA, выпустевшему сертификат (например: google.com, paypal.com или torproject.org). Причем она может действовать только когда сайт открыт через TLS, разрешая незащищённое соединение, но блокируя MitM с подменой сертификата.
Список из Chromium используют все популярные браузеры (Firefox, Safari и IE 11+Edge) и добавить в него сайт может любой желающий, если веб-сервер отдаёт заголовок Strict-Transport-Security со сроком действия от двух лет и ключевым словом preload в конце:
Как выстрелись себе в ногу?
На днях коллеги пожаловались на недоступность некоторых разделов сайта 1С (dist.1c.ru и partweb.1c.ru). Поддержка уверяла что всё работает, у меня проблема не воспроизводилась и даже у коллег сайты открылись из всех браузеров, кроме основного Chrome. Тот выдал ERR_CONNECTION_TIMED_OUT спустя 20 секунд и почему-то настойчиво подставлял HTTPS в URL, даже если адрес был написан полностью с HTTP.
Решение пришло почти сразу, так как недавно упоминали HSTS в контексте корпоративного MitM. Гуглёж по ключевому слову первой ссылкой подсказал, что посмотреть кэш политик можно в chrome://net-internals/#hsts и догадка подтвердилась:
Политика включала все субдомены, хотя многие из них были доступны только на 80 порту без TLS.
После её удаления нужные разделы стали открываться, по дате получения (в формате unix time) в истории браузера нашли страницу с неверными настройками и отправили багрепорт в 1С.
Вторым сайтом оказался ask.mcdonalds.ru, который открывался первый раз, однако Chrome всё равно показал предупреждение с уже знакомой четырёхбуквенной аббревиатурой и без привычной кнопки Proceed to (unsafe):
Ошибка говорит о несоответствии имени сертификата, окончании срока действия или его отзыве, а показ кнопки для открытия сайта прямо запрещён в RFC. При этом политика для mcdonalds.ru оказалась статической, которую нельзя удалить из chrome://net-internals/#hsts.
Обойти такую заглушку в Chrome можно набрав thisisunsafe (предыдущим волшебным словом были badidea, а до него danger) или запустив браузер с ключом —ignore-certificate-errors.
В Firefox надо нажать «Forge About This Site» напротив сайта в истории, открыть about:config и создать новый Integer с именем «test.currentTimeOffsetSeconds» и значением 11491200, а затем открыть сайт в новой вкладке.
Выводы
Не включайте потенциально опасные функции без понимания принципов их работы. Оценку «A» в тесте от SSL Labs вы получите и без HSTS, а включить его можно после проверки всего функционала через TLS. Со статическим листом в браузере пути назад уже не будет, поэтому лучше сразу приобрести сертификат с wildcard.
Chrome и Firefox поддерживают дополнительный механизм защиты: HTTP Public Key Pinning (HPKP), позволяющий привязать хэш сертификата и отправлять уведомление владельцу, если браузеру попадётся сертификат от публичного CA для его домена с другим хэшем. Он помог раскрыть несколько инциденов с публичными CA, но на практике используется очень редко из-за высокой цены ошибки.
Интересен состав захардкоженных политик в Chromium: кроме сети фастуда, нескольких доменов Mail.ru и Яндекса, там есть только ЮниКредит из ТОП-15 российски банков. Нет ни модного ТКС, ни Qiwi, ни WebMoney, а динамические политики оказались включены лишь у Qiwi и для адресов интернет-банков Бинбанка, МКБ, Открытия, Райффайзена и РСХБ.
Ещё там нет Телеграма, но есть Whatsapp, а в логе изменений встречаются запросы на удаление (!) ошибочно включенных сайтов, где какое-то время был preload в заголовке.
Загрузка...
