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

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

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

Достаточно, чтобы заинтересовать и немного покопать. «И шо ви таки думаете? (с)» В «насквозь безопасное» 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 сессия заканчивается на прокси.
Подробности тут.



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

UPD: В комментариях натолкнули на мысль, что то же самое может произойти если использовать смартфон «от оператора» с операторской прошивкой — вероятность нахождения на нем по умолчанию доверенного сертификата для всей инфраструктуры оператора близка к 100%.

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

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



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

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

Итого

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

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

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