Комментарии 22
Спасибо, подробно и доходчиво. А расскажите, пожалуйста, что-нибудь про производительность в режиме расшифровки SSL? Как показала практика, у некоторых вендоров с этим большая-большая беда — включая, скажем, отнюдь недешевые Checkpoint и Palo Alto.
Причем конкретные цифры никто не публикует, в отличие, например, от производительности IPS. А между тем, без расшифровки SSL DPI-фичи на 443 порту толком работать просто не будут, и весь NGFW превращается в тыкву.
Причем конкретные цифры никто не публикует, в отличие, например, от производительности IPS. А между тем, без расшифровки SSL DPI-фичи на 443 порту толком работать просто не будут, и весь NGFW превращается в тыкву.
По производительности cisco тоже не даёт точных цифр. Объясняют тем, что цифры очень зависят от дополнительных включенных сервисов: используется ли IPS, файловые политики и AMP и т.д.
В любом случае, вендор предупреждает, что не стоит использовать дешифрацию для всего подряд. Включайте дешифрацию только тогда, когда она действительно нужна.
Как раз в предыдущем материале я попробовал разобраться, для чего именно требуется дешифрация.
Ранее устройства-сенсоры SourceFIRE вообще не поддерживали дешифрацию. Для дешифрации нужно было покупать дополнительную железку — SSL Appliance. Это было связано именно с производительностью.
Возможно нам удастся протестировать в каком-либо виде устройство Cisco на предмет производительности при дешифрации. Если получится, обязательно поделимся результатами.
В любом случае, вендор предупреждает, что не стоит использовать дешифрацию для всего подряд. Включайте дешифрацию только тогда, когда она действительно нужна.
Как раз в предыдущем материале я попробовал разобраться, для чего именно требуется дешифрация.
Ранее устройства-сенсоры SourceFIRE вообще не поддерживали дешифрацию. Для дешифрации нужно было покупать дополнительную железку — SSL Appliance. Это было связано именно с производительностью.
Возможно нам удастся протестировать в каком-либо виде устройство Cisco на предмет производительности при дешифрации. Если получится, обязательно поделимся результатами.
Спасибо!
Вопрос — как в браузере (Yandex, IE) запретить переход на сайт, чей сертификат подменен таким образом?
Вопрос — как в браузере (Yandex, IE) запретить переход на сайт, чей сертификат подменен таким образом?
Рискну предположить, что никак. От подмены сертификата поможет техника Certificate pinning. Я кратко упоминал этот момент в тексте. Думаю, по вашего вопросу имеет смысл смотреть в этом направлении.
Локальный CA разве не перебивает эту политику, как сделано в Хроме?
Не совсем понял, что вы имеете в виду?
Chromium отключает HPKP для цепочек с приватными корневыми CA и они могут генерить сертификаты для любых сайтов, в том числе из захардкоженного списка.
То есть HPKP тоже не спасёт от подмены сертификата?
Оно спасаёт от публичных CA (и частных с кросс-сертификацией от них), которые начинают дурить. А отключение проверки для приватных рекомендуется прямо в RFC.
Спасибо огромное за оч толковую и емкую статью.
Битва меча и щита.
Прокси научились подменять сертификаты.
Браузеры научились проверять сертификаты (HPKP, привет).
Ждем ответа от щита (прокси).
Наверно, под давлением, производители браузеров HPKP сделают отключаемым, хотя бы в корпоративной среде. Либо прокси разрешат подключаться только через те браузеры, в которых HPKP отключен.
Прокси научились подменять сертификаты.
Браузеры научились проверять сертификаты (HPKP, привет).
Ждем ответа от щита (прокси).
Наверно, под давлением, производители браузеров HPKP сделают отключаемым, хотя бы в корпоративной среде. Либо прокси разрешат подключаться только через те браузеры, в которых HPKP отключен.
Отключение HPKP для приватных CA как раз обсуждали в коментах выше.
Прошу прощение если скажу глупость, но HPKP — это просто HTTP-заголовки в респонсах сервера. Если мы уж ломаем SSL на прокси, то что нам мешает там же подменить и заголовки? И браузер будет считать что вообще все хорошо…
Теоретически, да, можно резать заголовок. Но у меня есть чёткое подозрение, что в большинстве случаев это банально не требуется. Локальный CA перебивает политику HPKP и на этом всё заканчивается. На практике при внедрении FirePOWER мы пробовали включать дешифрацию, проблем с HPKP не встречали.
Чего-то грустно… Certificate pinning — это насколько я понял просто встраивание сертификатов в приложении. Если «попросят» встраивать нужный сертификат, как условие распространения приложения на территории страны, то выходит защиты нет совсем? Все это не означает что надо что-то серьезное и глобальное делать с handshake и как-то менять алгоритм?
Certificate pinning — это
Привязка к хэшу текущего публичного ключа через специальный HTTP заголовок Public-Key-Pins или Strict-Transport-Security, чтобы браузер не открывал сайты при его изменении в течении max-age.
Плюс в Chrome и FF есть захардкоженный список публичных ключей для google.com и ещё некоторых сайтов, который обновляется вместе с браузером. При их подмене браузер шлёт уведомление разработчикам (если подменяет не приватный CA).
Если «попросят» встраивать нужный сертификат, как условие распространения приложения на территории страны, то выходит защиты нет совсем?
В браузере он вряд ли появится, но могут заставить устанавливать при подключении к интернету.
Все это не означает что надо что-то серьезное и глобальное делать с handshake и как-то менять алгоритм?
В некоторые приложения встраивают публичный ключ своего сертификата, но с глобальным MitM они просто перестанут работать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Скучно о работе дешифрации NGFW