Chrome и Safari не соблюдают HPKP

Я добавил заголовок HPKP на свой сайт, но он не поддерживается Chrome или Safari. Проверил вручную, установив прокси и зайдя на chrome://net-internals/#hsts и поискав свой домен - не нашел. HPKP кажется правильным, и я также проверил его с помощью набора инструментов HPKP, поэтому я знаю, что он действителен.

Я думаю, что, возможно, я делаю что-то странное со своим потоком. У меня есть веб-приложение, которое обслуживается через myapp.example.com. При входе в систему приложение перенаправляет пользователя на authserver.example.com/begin, чтобы инициировать поток кода авторизации OpenID Connect. Заголовок HPKP возвращается только из authserver.example.com/begin, и я думаю, что это может быть проблемой. У меня есть include-subdomain в заголовке HPKP, поэтому я думаю, что это не проблема.

Это заголовок HPKP (разрывы строк добавлены для удобочитаемости):

public-key-pins:max-age=864000;includeSubDomains; \
pin-sha256="bcppaSjDk7AM8C/13vyGOR+EJHDYzv9/liatMm4fLdE="; \
pin-sha256="cJjqBxF88mhfexjIArmQxvZFqWQa45p40n05C6X/rNI="; \
report-uri="https://reporturl.example"

Спасибо!


google-chrome security http-headers hsts
person Omer Levi Hevroni    schedule 23.03.2017    source источник
comment
Это не ограничивается Chrome и Safari. Все современные браузеры делают это; и многие веб-компоненты делают это, потому что это функция модели веб-безопасности.   -  person jww    schedule 24.03.2017

Ответы (2)


arrow_upward
1
arrow_downward

Я добавил заголовок HPKP на свой сайт, но он не поддерживается Chrome или Safari... Я протестировал его вручную, установив прокси...

RFC 7469, расширение для закрепления открытого ключа для HTTP, как бы прокрадывается мимо вас. IETF опубликовал его с переопределениями, поэтому злоумышленник может сломать заведомо исправный пинсет. Один раз упоминается в стандарте под названием "override", но подробности не приводятся. IETF также не смогла опубликовать обсуждение в разделе, посвященном вопросам безопасности.

Более того, прокси, который вы установили, задействовал переопределение. Не имеет значения, является ли это неправильным прокси-сервером, сертификатом прокси-сервера, установленным OEM-производителем мобильного устройства, или прокси-сервером, контролируемым злоумышленником, который обманом установил пользователя. Модель веб-безопасности и стандарт допускают это. Они приветствуют перехват и считают его допустимым вариантом использования.

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

Лучший способ избежать этого — выйти за пределы модели веб-безопасности. Не используйте приложения на основе браузера, если вас беспокоит безопасность. Используйте гибридное приложение и выполните закрепление самостоятельно. Ваше гибридное приложение может размещать элемент управления или представление WebView, но при этом получать доступ к каналу для проверки параметров. См. также закрепление сертификата и открытого ключа OWASP.

См. также Комментарии к draft-ietf-websec-key-pinning в списке рассылки IETF. Одним из предложений в комментарии было изменить заголовок на "Расширение для закрепления открытого ключа для HTTP с переопределениями", чтобы выделить эту функцию. Неудивительно, что это не то, чего они хотят. Они пытаются сделать это тайком, без ведома пользователя.

Вот соответствующий текст из RFC 6479:

2.7. Взаимодействие с предварительно загруженными списками выводов

UA МОГУТ реализовать дополнительные источники информации о закреплении, например, с помощью встроенных списков информации о закреплении. Такие UA должны позволять пользователям переопределять такие дополнительные источники, в том числе отключать их от рассмотрения.

Эффективная политика для известного закрепленного хоста, который имеет как встроенные выводы, так и выводы из ранее наблюдаемых полей ответа заголовка PKP, определяется реализацией.

person jww    schedule 24.03.2017
comment
Спасибо за подробный ответ! Я оставил комментарий к ответу ниже, но, поскольку ваш ответ очень похож, я думаю, он имеет отношение и к этому ответу. - person Omer Levi Hevroni; 26.03.2017

arrow_upward
1
arrow_downward

Локально установленные центры сертификации (например, те, которые используются для прокси-серверов, как вы говорите, работают) переопределяют любые проверки HPKP.

Это нужно, чтобы не ломать интернет полностью, учитывая их распространенность: антивирусное ПО и прокси, используемые в крупных корпорациях, в основном MITM https-трафик через локально выданный сертификат, иначе они не смогли бы прочитать трафик.

Некоторые утверждают, что для локальной установки ЦС требуется доступ к вашей машине, и на этом все равно игра окончена, но для меня это все еще значительно снижает защиту HPKP, и это, в сочетании с высокими рисками использования HPKP, означает, что я действительно не фанат этого.

person Barry Pollard    schedule 24.03.2017
comment
Так какой смысл в HPKP? Может я что-то упускаю... И еще, почему я не мог видеть настройки в chrome://net-internals/#hsts? Если вы говорите правду, я ожидаю увидеть ее там, хотя она переопределяется локальным прокси-сервером... - person Omer Levi Hevroni; 26.03.2017
comment
HPKP полезен только для трафика без прокси. Как я уже говорил, для меня это большая (но необходимая, чтобы не сломать множество пользователей) дыра, поскольку это означает, что она не защищает от атак, подобных Superfish. Да, я принимаю во внимание, что если локальный ПК скомпрометирован, вы мало что можете сделать, но все равно это кажется большой дырой. И это, плюс учитывая опасности, которые HPKP может так (из-за того, что владельцы сайтов совершают самоубийство), означают, что я действительно не думаю, что это стоит усилий. - person Barry Pollard; 26.03.2017
comment
Политика сохраняется в chrome://net-internals/#hsts только в том случае, если политика была проверена. Это необходимо для предотвращения сохранения недействительной политики и нарушения работы сайта. Если вы посещали только через прокси-сервер, то политика HPKP никогда не была действительной (поскольку ни один из контактов не использовался для этого соединения), поэтому политика игнорируется. Если вы посещаете его без прокси-сервера, он должен быть сохранен и доступен на этой странице. Также обратите внимание, что для действительной политики должны использоваться два полностью независимых контакта, поэтому, если вы закрепляете только корневой сертификат ЦС и конечный сертификат, и оба используются в одной цепочке, это не сработает. - person Barry Pollard; 26.03.2017
comment
Что я сделал, так это посетил его один раз без прокси-сервера, а затем один раз с прокси-сервером, поэтому он должен быть проверен. Я также использовал 2 разных вывода (производственный и резервный). Но я думаю, что я собираюсь удалить HPKP, так как не вижу смысла использовать его в любом случае... - person Omer Levi Hevroni; 26.03.2017
comment
Согласитесь, это должно было подтвердиться тогда. Можете действительно сказать, почему это не так, не видя реального сайта и сертификатов, которые у вас есть для этого. - person Barry Pollard; 26.03.2017
comment
Выяснил, почему не отображается в chrome://net-internals/#hsts: проверил на example.com, а не на authserver.example.com. Досадная ошибка... - person Omer Levi Hevroni; 26.03.2017
comment
Прохладный. Приятно знать, что это работает так, как я думал :-) - person Barry Pollard; 26.03.2017