Комментарии 7
У меня вопрос по картинке в шапке — кто такие Пэт и Джейн и что случилось с Алисой и Бобом?
Это друзья Алисы и Боба, которые не столь сведущи в криптографии, поэтому пока что романтические попытки Пэта признаться в любви Джейн оканчиваются провалом из-за «человека посередине».
Еще, как вариант — Алиса и Боб уехали в отпуск.
Как Вам больше нравится :)
Еще, как вариант — Алиса и Боб уехали в отпуск.
Как Вам больше нравится :)
НЛО прилетело и опубликовало эту надпись здесь
Так и не понял из статьи. OCSP Must Staple (a.k.a. `TLS Feature/Status Request`) первой и второй версии отличаются только наличием возможности прикрепить OCSP для intermediate? Или в первой версии таки нашли «фатальный недостаток»? RFC курить пока не очень хочется.
Достаточно ли v1 (+ HPKP + HSTS) для безопасности от MITM? Какие CA и веб-серверы поддерживают v2 (с OCSP для промежуточных сертификатов)?
Достаточно ли v1 (+ HPKP + HSTS) для безопасности от MITM? Какие CA и веб-серверы поддерживают v2 (с OCSP для промежуточных сертификатов)?
«TLS feature» и «status request» — это разные вещи. У «TLS featue» (оно же «OCSP must staple») только одна версия. Две версии у «status request» (оно же «прикреплённые OCSP-ответы», оно же «OCSP stapling», оно же «status_request» и «status_request_v2»). Но давайте по порядку.
У расширения «TLS feature» только одна версия. «TLS Feature» — это специальное поле в сертификате сервера, сообщающее клиенту о том, что сервером поддерживается определённый набор фич протокола TLS. Это поле в сертификате нужно для того, чтобы защититься от даунгрейд-атак на TLS-соединение, которые «человек посередине» может попытаться провести. Такая защита работает, поскольку «человек посередине» не может изменить сертификат сервера и удалить/модифицировать поле «TLS feature». Иначе говоря, список поддерживаемых сервером TLS-фич жестко фиксируется в сертификате сервера и с этим «человек посередине» ничего не может поделать.
У протокола TLS много необязательных фич, которые можно было бы перечислить и зафиксировать в поле «TLS feature», однако в этой статье мы рассматриваем только одну из них, а именно, так называемые прикреплённые OCSP-ответы.
Пример даунгрейд-атаки на эту фичу протокола TLS приведён в начале статьи: «человек посередине» выдаёт себя за сервер, не поддерживающий прикреплённые OCSP-ответы. Если в сертификате сервера отсутствует поле TLS feature, то у клиента нет возможности отличить «человека посередине», проводящего даунгрейд-атаку, от сервера, не поддерживающего прикреплённые OCSP-ответы.
У прикреплённых OCSP-ответов как раз две версии. Первая версия обладает значительным недостатком: она позволяет «прикрепить» (предать клиенту средствами протокола TLS) только OCSP-ответ для сертификата самого сервера. Это означает, что статус остальных сертификатов из цепочки нужно проверять иным способом. Вторая версия исправляет этот недостаток и позволяет «прикрепить» все необходимые OCSP-ответы.
Поддержка второй версии («status_request_v2») — это фича не самого веб-сервера, а используемой им библиотеки, реализующей TLS. Насколько нам известно, ни одна из популярных библиотек (Schanel, OpenSSL, GnuTLS, LibreSSL, NSS) её не поддерживает.
Прикреплённые OCSP-ответы версии 1 (как и версии 2) без «TLS feature» не позволяют защититься от атаки, описанной в данной статье, из-за возможности даунгрейда. HPKP+HSTS защитят, если клиент успел обновить pin-ы до появления «человека посередине», поскольку «человек посередине» может блокировать обновление pin-ов, вырезав необходимые заголовки из HTTP-ответа.
Спасибо за комментарий!
У расширения «TLS feature» только одна версия. «TLS Feature» — это специальное поле в сертификате сервера, сообщающее клиенту о том, что сервером поддерживается определённый набор фич протокола TLS. Это поле в сертификате нужно для того, чтобы защититься от даунгрейд-атак на TLS-соединение, которые «человек посередине» может попытаться провести. Такая защита работает, поскольку «человек посередине» не может изменить сертификат сервера и удалить/модифицировать поле «TLS feature». Иначе говоря, список поддерживаемых сервером TLS-фич жестко фиксируется в сертификате сервера и с этим «человек посередине» ничего не может поделать.
У протокола TLS много необязательных фич, которые можно было бы перечислить и зафиксировать в поле «TLS feature», однако в этой статье мы рассматриваем только одну из них, а именно, так называемые прикреплённые OCSP-ответы.
Пример даунгрейд-атаки на эту фичу протокола TLS приведён в начале статьи: «человек посередине» выдаёт себя за сервер, не поддерживающий прикреплённые OCSP-ответы. Если в сертификате сервера отсутствует поле TLS feature, то у клиента нет возможности отличить «человека посередине», проводящего даунгрейд-атаку, от сервера, не поддерживающего прикреплённые OCSP-ответы.
У прикреплённых OCSP-ответов как раз две версии. Первая версия обладает значительным недостатком: она позволяет «прикрепить» (предать клиенту средствами протокола TLS) только OCSP-ответ для сертификата самого сервера. Это означает, что статус остальных сертификатов из цепочки нужно проверять иным способом. Вторая версия исправляет этот недостаток и позволяет «прикрепить» все необходимые OCSP-ответы.
Поддержка второй версии («status_request_v2») — это фича не самого веб-сервера, а используемой им библиотеки, реализующей TLS. Насколько нам известно, ни одна из популярных библиотек (Schanel, OpenSSL, GnuTLS, LibreSSL, NSS) её не поддерживает.
Прикреплённые OCSP-ответы версии 1 (как и версии 2) без «TLS feature» не позволяют защититься от атаки, описанной в данной статье, из-за возможности даунгрейда. HPKP+HSTS защитят, если клиент успел обновить pin-ы до появления «человека посередине», поскольку «человек посередине» может блокировать обновление pin-ов, вырезав необходимые заголовки из HTTP-ответа.
Спасибо за комментарий!
Вся схема онлайн проверки сертификатов видится мне изначально порочной. Как в плане безопасности, так и, что немаловажно, приватности.
Более перспективной же, на мой взгляд, является технология глобального распределенного списка отозванных сертификатов (улучшенный CRL), работа с которым будет явно вынесена на уровень пользователя: кнопки «обновить список опасных сайтов», " автоматически обновлять каждые Х минут", большой красный алерт в верху окна «список опасных сайтов не обновлялся с… [Обновить] [Да кому я нужен]», в настройки — максимальный срок устаревания, после которого проверка сертификата браузером фейлится.
Обновлять список, естественно, диффами по стандартной схеме, плюс сервак может отсылать кусочек списка, относящийся лично к нему (по запросу или степлить).
Более перспективной же, на мой взгляд, является технология глобального распределенного списка отозванных сертификатов (улучшенный CRL), работа с которым будет явно вынесена на уровень пользователя: кнопки «обновить список опасных сайтов», " автоматически обновлять каждые Х минут", большой красный алерт в верху окна «список опасных сайтов не обновлялся с… [Обновить] [Да кому я нужен]», в настройки — максимальный срок устаревания, после которого проверка сертификата браузером фейлится.
Обновлять список, естественно, диффами по стандартной схеме, плюс сервак может отсылать кусочек списка, относящийся лично к нему (по запросу или степлить).
Вы отчасти правы. Похожую схему, хотя и без подробностей в описании реализации клиентской стороны и UI, мы описали в разделе «Схема для большинства» статьи.
Описанная вами схема действительно подходит для большинства случаев, однако она всё же оставляет окно для атаки: её всё ещё можно провести между обновлениями списка отозванных сертификатов. Это может быть неприемлемо для некоторых особо критичных к безопасности сервисов. К слову, это не обязательно могут быть веб-сервисы.
Другие возникающие вопросы — это: где хранить этот глобальный список и насколько он будет большим? Если его хранить локально, то на все ли устройства он поместится? Если хранить удалённо, то снова возвращаемся к вопросу о «человеке посередине». Если сокращать его размер, то возникает вопрос о его полноте. Но с этим, опять же, могут помочь сертификаты с коротким сроком действия.
В Google рассматривали подход, аналогичный Certificate Trancparency. Он тоже похож на обсуждаемую схему и называется «Revocation Transparency». Про него можно почитать вот тут. Насколько нам известно, его пока не планируют реализовывать.
К вопросу о «приватности», если мы вас правильно поняли, то он решается с помощью прикреплённых OCSP-ответов (OCSP stapling).
Благодарим за дополнение!
Описанная вами схема действительно подходит для большинства случаев, однако она всё же оставляет окно для атаки: её всё ещё можно провести между обновлениями списка отозванных сертификатов. Это может быть неприемлемо для некоторых особо критичных к безопасности сервисов. К слову, это не обязательно могут быть веб-сервисы.
Другие возникающие вопросы — это: где хранить этот глобальный список и насколько он будет большим? Если его хранить локально, то на все ли устройства он поместится? Если хранить удалённо, то снова возвращаемся к вопросу о «человеке посередине». Если сокращать его размер, то возникает вопрос о его полноте. Но с этим, опять же, могут помочь сертификаты с коротким сроком действия.
В Google рассматривали подход, аналогичный Certificate Trancparency. Он тоже похож на обсуждаемую схему и называется «Revocation Transparency». Про него можно почитать вот тут. Насколько нам известно, его пока не планируют реализовывать.
К вопросу о «приватности», если мы вас правильно поняли, то он решается с помощью прикреплённых OCSP-ответов (OCSP stapling).
Благодарим за дополнение!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Человек посередине», использующий отозванные сертификаты. Часть 2