`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Арсен Бандурян

Так ли приватен HTTPS?

+66
голосов

Недавно в одном из прочитанных блогов увидел интересное утверждение (в моем вольном переводе):

Думаете, когда вы работаете с онлайн-банкингом из офиса, у вас сквозное безопасное соединение? Подумайте еще разок.

Достаточно, чтобы заинтересовать и немного покопать. Оказалось, что в "насквозь безопасное" HTTPS соединение можно врезать как минимум двух посредников (Man In The Middle). Правда, оба должны быть Trusted (TMITM), так что не надо сильно паниковать. Пока что.

Вариант 1: корпоративный/операторский файрвол или прокси

В корпоративных сетях пользователи обычно выходят в Интернет через прокси, который может быть задан явно или неявно (transparent или просто продвинутый firewall). Это необходимо для поддержания хотя-бы минимального корпоративного контроля над трафиком (фильтрация нежелательных сайтов/скриптов/рекламы, антивирусные проверки, кеширование и т.д.) и, в принципе, логично.

Абсолютно понятно, как это работает для нешифрованного HTTP, а вот с HTTPS - понятно не все. Ведь HTTPS как раз и предназначен для защиты от "врезания" в сессию и перехвата трафика: данные шифруются, а аутентичность сервера проверяется сертификатами. Так что, возникают как минимум два вопроса:

  1. Почему я должен доверять сертификату прокси?
  2. Даже если я доверяю сертификату прокси, он же выпущен на имя прокси, а не на имя моего банка - как он может сработать?

Выходит, что может.

Первый вопрос вообще не возникает, если в компании развернута собственная инфраструкра сертификатов и есть свой CA. В таком случае, сертификат этого CA будет установлен как доверенный на каждой рабочей машине, и всё, что будет подписано этим же сертификатом (наш прокси) также будет доверенным. Именно из-за этого подобное "доверенное" (Trusted) внедрение и становится возможным в этом сценарии.

Но что делать с неправильным именем в сертификате? Существует (и довольно давно) класс программ типа MITMproxy или HoneyProxy, которые этот вопрос успешно решают. Их основная функция - читить в Apple GameCenter генерировать сертификаты на лету! Прокси устанавливается в качестве промежуточного CA (подписанного Enterprise Root CA) и динамически генерирует сертификаты (для себя же) на любое имя. Таким образом, клиент думает, что он общается с банком, хотя, на самом деле, его HTTPS сессия заканчивается на прокси. Подробности тут.

image

Так что, исходное утверждение оказалось верным, и верить рабочим HTTPS-соединениям можно лишь настолько, насколько можно верить своему ИТ-отделу. Или же использовать браузер вроде Firefox, у которого имеется свое, независимое от ОС, хранилище сертификатов и поддержка Certificate Pinning (не так давно ставшая популярной в браузерах). Ну, или, конечно же, не использовать рабочие машины в рабочей сети в нерабочих целях, но кто будет следовать этому глупому правилу? VPN тоже может помочь, если он не на основе SSL.

То же самое может произойти если использовать смартфон "от оператора" с операторской прошивкой - вероятность нахождения на нем по умолчанию доверенного сертификата для всей инфраструктуры оператора близка к 100%.

Вариант 2: Облачный бесключевой прокси CloudFlare

Хорошо, администратор моей работчей сети может мониторить мои соединения с рабочей машины. Ну да ладно. Во всяком случае, целевой сервер, к которому я подключаюсь должен быть аутентичным - иначе прокси запаникует и не построит до него HTTPS-сессию (если только админы не накосячили с настройкой). В свете недавнего анонса Keyless SSL от CloudFlare, похоже, это уже тоже не факт.

image

Технические подробности можно почитать тут. Для нас важно то, что в данном сценарии уже целевой сервер (тот же онлайн-банкинг), оказывается, уже банку не принадлежит! Хорошая новость в том, что он принадлежит кому-то, кому банк доверяет.

Товарищи из CloudFlare разработали способ представляться HTTPS-сервером заказчика без необходимости подделывать сертификаты или даже подписываться ключами заказчика. По факту, как раз проверка аутентичности проводится с сервером банка, но как только она пройдена - сеанс устанавливается с доверенным сервером CloudFlare. Цель благородна - разгрузка HTTPS-трафика клиентов и защита от DDoS-атак. Сколько времени понадобится на изобретение метода имперсонации целевого сервера без необходимости получать его сертификаты и ключи (или как быстро "органы" разных стран затребуют себе бекдор-доступ) - кто его знает. Надеюсь, достаточно долго.

Итого

В, казалось бы, "безопасном от и до" HTTPS соединении могут успешно поселиться как минимум два посредника. Оба должны быть доверенными, но доверяет им ваш админ, ваш босс, ваш банк, ваш магазин - только не вы. Если вы думаете, что в Интернете еще есть 100% приватность - подумайте еще разок.

А вы знаете какие-то еще методы атак на HTTPS?

P.S. Оригинал тут.

+66
голосов

Напечатать Отправить другу

Читайте также

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT