Известные проблемы фильтрации HTTPS

Статья обновлена 3 апреля 2018
Ознакомление с этой статьей может потребовать от вас базовых знаний о шифровании, протоколе TLS и устройстве HTTPS.

Для начала, приведем диаграмму, которая показывает, как в целом устроена фильтрация HTTPS в AdGuard:

What is HTTPS filtering

AdGuard копирует свойства TLS-соединения, которые использует ваш браузер:

  • AdGuard использует ту же самую версию TLS.
  • AdGuard использует те же методы шифрования (ciphers), что и ваш браузер.

Так что если вы используете современный и безопасный браузер - это хорошо, ведь известные проблемы TLS в нем уже учтены, и он не будет пытаться использовать небезопасные методы шифрования.

Как ведет себя AdGuard в случае, если есть сомнения в валидности сертификата?
В случае, если есть какие-то сомнения в валидности сертификата, AdGuard полностью прекращает фильтрацию соединений к этому домену, и отдает это на откуп браузеру.

Известные недостатки

Фильтрация HTTPS в AdGuard имеет некоторые недостатки. Практически все мы планируем устранить в ближайших версиях AdGuard. Более того, мы ведем работу над отдельной библиотекой валидации сертификатов и хотим выложить ее код в открытый доступ.

Ниже перечислены все известные нам проблемы и сроки их устранения.

Проверка на отзыв сертификата (OCSP revocation check)

В сообществе интернет-безопасности есть определенные разногласия на предмет того, насколько вообще полезны OCSP проверки. Например, разработчики Chrome считают, что этот подход не выдерживает критики, и предлагают альтернативное решение. Более того, Android вообще не поддерживает и не использует (и не будет) OCSP-проверки.

Поведение AdGuard зависит от платформы. AdGuard для Windows использует Microsoft CryptoAPI для совершения OCSP-проверок, которое имеет все те недостатки, что были описаны разработчиками Chrome. AdGuard для Android - не совершает их совсем.

Что мы хотим сделать:

  • Добавить в библиотеку валидации возможность использования CRLSets (альтернативное OCSP решение от Google)
  • Добавить в библиотеку поддержку функции OCSP Must-Staple
  • Добавить поддержку заголовка Expect-Staple
  • Отказаться от CryptoApi в пользу кросс-платформенной реализации проверки OCSP

Срок реализации:

Данные изменения будут сделаны после окончания разработки нового кросс-платформенного движка фильтрации, что ожидается в Q2-Q3 2018.

Certificate Transparency

Благодаря совеременной криптографии бразуеры обычно могут легко обнаружить вредоносные сайты с подделанными сертификатами. Однако, этих механизмов недостаточно для обнаружения вредоносных сайтов, которые используют сертификаты, выданные по ошибке настоящим (но, к примеру, скомпрометированным) центром сертификации. Certificate Transparency призван стать защитой от подобного рода угроз, сделав процедуру выдачи SSL сертификатов открытой и прозрачной для всех.

В нашем случае проблема в том, что браузеры игнорируют заголовок Expect-CT для локальных сертификатов, и проверка на certificate transparency просто не производится при включенном AdGuard. Для того, чтобы получить тот же уровень защиты, мы должны самостоятельно проводить эту проверку на уровне AdGuard.

Что мы хотим сделать:

  • Добавить поддержку Certificate Transparency в библиотеку валидации

Срок реализации:

  • Мы планируем включить этот функционал после того, как все продукты AdGuard будут переведены на новый движок фильтрации: Q3-Q4 2018.

Поддержка HPKP

HPKP (HTTP Public Key Pinning) - механизм, который позволяет сайтам защищаться от попыток несанкционированного перехвата защищенных (HTTPS) соединений к ним. Этот стандарт пока используется не очень широко (из топ 1000 сайтов по Alexa, HPKP используется менее чем на 1%) из-за высоких рисков при использовании и сложности в настройке. Некоторые специалисты вообще считают, что он де-факто мертв. Тем не менее, он остается единственным защитным механизмом, который будет работать в случае компрометации центра сертификации.

При использовании фильтрации HTTPS возникает одна серьезная проблема - HPKP полностью игнорируется браузерами (так как он не используется при использовании локального корневого сертификата). Это - общая проблема для программ, фильтрующих HTTPS. Единственным возможным решением на данный момент является реализация стандарта HPKP в самом AdGuard.

Что мы хотим сделать:

  • Добавить поддержку HPKP в библиотеку валидации
  • Изменить поведение AdGuard в случае, если мы встречаем невалидный сертификат. Вместо текущего поведения (прекращаем фильтрацию для домена), мы должны предупреждать пользователя о возникшей проблеме.

Срок реализации:

  • Мы планируем включить этот функционал после того, как все продукты AdGuard будут переведены на новый движок фильтрации: Q3-Q4 2018.

Замечание: Намерения Google по отказу от поддержки HPKP вносят определенные осложнения, что в итоге может помешать нашим планам.
+

Поддержка TLS v1.3

На данный момент последней стабильной версией TLS является версия 1.2, которая датируется 2008 годом. Этот протокол вполне безопасен при условии, что он корректно настроен. С другой стороны, неправильная настройка приводит к уязвимостям: POODLE, FREAK, Logjam и другим.

Новая версия TLS все еще находится в разработке, но уже поддерживается некоторыми браузерами и некоторыми известными веб-сайтами.

Основными плюсами TLS 1.3 являются:

  • Увеличение скорости соединения
  • Улучшенная безопасность

Улучшенная безопасность достигается за счет отказа от поддержки старых уязвимых стандартов, которыми, в теории, могут воспользоваться злоумышленники в случае TLS 1.2.

На данный момент ситуация с поддержкой TLS 1.3 в браузерах следующая:

  • Firefox - поддерживает, TLS 1.3 включен и используется
  • Chrome - поддерживает, TLS 1.3 выключен по умолчанию (может быть включен в chrome://flags)
  • Safari - не поддерживает
  • Edge - не поддерживает

Что мы хотим сделать:

  • Новый движок фильтрации поддерживает TLS 1.3 так что все версии AdGuard скоро получат поддержку TLS 1.3.

Срок реализации:

Q2-Q3 2018

Предупреждение Obsolete Key Exchange (RSA)

При проверке свойства HTTPS соединения в Chrome, вы можете увидеть предупреждение:

Obsolete Key Exchange

Дело в том, что AdGuard поддерживает два зашифрованных соединения. Одно - с браузером, другое - с сервером. Для соединения с браузером мы используем более простое шифрование для лучшей скорости.

Что мы хотим сделать:

  • Добавить использование более современного алгоритма обмена ключами в бета-версию AdGuard для Windows.
  • В случае, если производительность нас не устроит, оставить старый алгоритм, но добавить флаг для включения более современного в настройки AdGuard.

Срок реализации:

  • AdGuard для Windows 6.2 с обновленным алогритмом вышел в конце октября 2017. (UPD: готово)
  • В Mac-версии уже используется современный алгоритм.
  • В Android-версию исправление попадет в версии 3.0 (ориентировочно, Q2 2018 года).

Замечания и пожелания?

Если вы хотите что-то добавить, указать нам на ошибки или несоответствия или задать вопрос, пишите пожалуйста на адрес devteam at AdGuard.com.