Комментарии 21
Нельзя такое делать на транспортном уровне — согласие это просто один бит да/нет, его слишком легко подделать, скрыть, получить от пользователя обманом, или вообще игнорировать. Про этот принцип уже немало писали: нельзя сделать софт, который позволил бы прослушивать трафик террористов и педофилов, но при этом не дал бы возможности прослушивать вообще всех подряд.
Если пользователь хочет дать доступ к своему трафику — этот доступ необходимо реализовывать непосредственно на одном из концов шифрованного соединения (напр. в браузере пользователя). Нет ничего плохого в том, чтобы браузер предоставлял API для антивирусов и прочих инструментов, которые пользователь должен сначала установить на свой комп, и потом открыть им доступ к конкретному браузеру — вот это будет вполне приемлемой формой получения согласия пользователя слушать его трафик.
В корпоративной среде установку/подключение таких инструментов можно автоматизировать, а инструмент на компах юзеров вполне может быть тонким агентом, который прогоняет трафик для анализа через централизованный сервис компании.
Собственно, такие API уже есть: браузерные плагины имеют доступ к трафику, плюс имеют возможность коммуникации с локально установленными приложениями.
Т.е. браузер должен давать явное согласие на участие mitm'а (и сервер с своей стороны тоже). Никакого wiretapping, просто участие third party.
Что значит "общего ключа для передачи"? Насколько этот общий ключ вычисляется с поддержкой адекватных алгоритмов, насколько поддерживает forward secrecy, etc. — т.е. насколько использование такого MITM сделает коммуникацию более уязвимой по сравнению с вариантом без MITM? Учитывая среднее качество таких инструментов, хорошо описанное в данной статье — это явно плохая идея. Канал сайт-браузер должен быть защищён. А что там пользователь добровольно делает с полученными браузером данными — кому их передаёт и как при этом шифрует — это уже его личное дело.
Разрешит Алиса участвовать Клэр в этом процессе или нет — вопрос настроек браузера Алисы.
А мой комментарий был, что модель SSL не соответствует его применению в энтерпрайзе. И это порождает хаки, которые значительно хуже, чем признание наличия Клэр в протоколе.
Да, не соответствует. Да, порождает. Нет, признавать этот факт и менять протокол всё-равно плохая идея, и мой комментарий был о том, почему это плохая идея: мы не сможем гарантировать, что никто кроме уважаемой в нашей компании Клэр не использует эту дырувозможность протокола без нашего ведома. В текущем виде протокол, по крайней мере, очень старается исключить MITM либо сделать его применение очень неудобным и/или заметным. Если протокол будет допускать "доверенный MITM", то отличать доверенный от недоверенного и контролировать наличие MITM в принципе станет намного сложнее.
Согласитесь, что ткнуть в адресную строку и посмотреть «кто именно ещё участвует» куда удобнее, чем сидеть с strace'ом/tcpdump'ом и вылавливать кто там что кому подменяет.
А административные вопросы как раз станут лучше. Сейчас есть разумная причина для CA, который подписывает что попало. Если mitm станет официальной частью, это причина исчезнет, и любой CA, который подписывает чужие сервера, станет очевидным злоумышленником.
Насчёт гэбни — это не сделает их жизнь легче. Браузер предоставляет возможность не доверять третьей стороне. (Гэбня может за это не пускать трафик, но это уже другой вопрос — сейчас они с тем же успехом могут резать чужой SSL).
Зачем tcpdump?
Неплохой вариант: что бы это разрешать по идее должен быть только 1 метод — доменные политики, и при установке такой политики в MITM:true — в заголовке хрома указывать:
«Ваш сетевой администратор имеет полный доступ к вашему трафику»
Если продолжить идею — такой заголовок надо бы передавать веб-серверам, т.к возможно не все сайты согласятся давать трубу, которая доступна третьей стороне.
Соединение (полный вариант с всеми возможными опциями) выглядело бы так:
Пользователь: Сертификат выписан CA-таким-то.
Proxy пользователя: сертификат подписан тем-то, разрешение на участие в соединении выдано (согласие пользователя/настройки браузера/доменная политика/etc)
Proxy сервера: сертификат cloudflare, подписанный сертификатом сервера example.com
Example.com: сертификат от Let's Encrypt.
Всё понятно, ясно, у пользователя есть возможность видеть всех их, видеть почему каждый из них в процессе участвует, возможность забанить любого из (возможно/нет — это уже локальные настройки браузера).
Вместо этого у нас супердырявые MITM'ы, которые скрывают от пользователя оригинальные сертификаты.
На сколько мне известно на стороне клиента — нет. Если корневой сертификат стоит, то все его дочерние сертификаты (т.е. в рамках дерева доверия) будут автоматически верны.
Собственно, на этом и основаны прокси.
Нечто подобное пытаются внедрять: Certificate Transparency.
Я тоже считаю, что некие «зоны ответственности» у корневых сертификатов должны быть определены. Пусть даже на уровне DNS (с новыми протоколами DOT, DOH и т.п.), можно было бы прописать некую TXT-запись, в которой указать кто ответственен за данный домен. Хотя, это не панацея, нужно придумать механизм распространения этих данных.
Беда в том, что это не нужно рынку. Красная или не красная плашка это блаж и фича, ничего, по сути, не меняющая.
А вот реализация "это проверяем так, а то — эдак на стороне клиента" приведет к падению работы всей infosec какая она есть сей час.
Вообще же, если говорить серьезно, то нужно сделать, так это вернуть обратно HPKI, который как раз эту проблему и решал (как я понимаю), но был выпелен под благие лозунги. А стоило бы оставить...
Новые инструменты для обнаружения HTTPS-перехвата