Apache: проверять цепочку доверия SSL для предотвращения MITM-атак?

11

Я только что понял, что атаки типа «человек посередине» SSL встречаются гораздо чаще, чем я думал, особенно в корпоративных средах. Я слышал и видел несколько предприятий, которые имеют прозрачный прокси-сервер SSL. Все клиенты настроены на доверие к сертификату этого прокси. Это в основном означает, что работодатель теоретически может перехватывать даже зашифрованный трафик SSL без каких-либо предупреждений в браузере. Как упомянуто выше, клиенты идут с доверенным сертификатом. Это может быть выявлено только путем ручной проверки используемого сертификата.

Мне кажется, что работодатель использует свое превосходящее положение, чтобы шпионить за SSL-трафиком сотрудника. Для меня это делает всю концепцию SSL ненадежной. Я успешно протестировал подобную настройку, используя mitmproxy, и смог прочитать связь между клиентом и моим сервером электронного банкинга. Это информация, которая никому не должна раскрываться.

Таким образом, мой вопрос довольно прост: как я могу проверить цепочку доверия на стороне сервера? Я хочу убедиться, что клиент использует сертификат моего сервера и только одну цепочку доверия. Интересно, может ли это быть достигнуто конфигурацией SSL Apache? Это было бы удобно, так как его можно легко применить ко многим приложениям. Если это невозможно, кто-нибудь знает способ сделать это на PHP? Или у вас есть другие предложения?

— Aileron79
источник

1

Это нормально, если работодатель видит движение сотрудников. Вы используете ресурсы работодателя (компьютер, сетевые подключения и т. Д.), Они не ваши. И если вы беспокоитесь, что emplyer может видеть данные, которые вы передаете на свой банковский счет - делайте это дома, а не на работе. И попытки нарушить корпоративную политику безопасности могут стать предметом судебного разбирательства против вас.

— Crypt32

2

Во многих европейских компаниях частное использование оргтехники регулируется договором найма. В компании, где я работаю, я могу заниматься серфингом в частном порядке, это не проблема. Есть исключения , как порно, обмен файлами и т.д. В то же время есть законы , которые запрещают компании Шпионаж на своих сотрудников. Таким образом, для меня - и многих других - это не нормально, когда работодатели перехватывают трафик сотрудников, поскольку это явно запрещено, в то время как частный серфинг допускается во многих компаниях.

— Aileron79

2

Большинство (по моему опыту) принадлежащих правительству США рабочих станций включают эти два уведомления при каждом входе в систему: «Сообщения, использующие эту информацию или хранящиеся на ней, не являются частными, подлежат регулярному мониторингу, перехвату и поиску и могут быть раскрыты или использованы для любой санкционированной цели правительства США. Это включает меры безопасности (например, аутентификацию и контроль доступа) для защиты интересов правительства США, а не для вашей личной выгоды или конфиденциальности ". Использование этих систем часто подпадает под действие подписанного соглашения, предусматривающего то же самое. Ключевая деталь: владелец системы защищает себя от вас.

— Рэндалл

Это одно из многих различий между США и Европой. Приведенные выше термины @Randall являются незаконными в большинстве европейских стран.

— Aileron79

Приведенные мною термины являются неполными, в других терминах перечислены действия, которые явно не подлежат мониторингу. Я не могу найти ссылку на то, что европейские работодатели не могут сделать такие предварительные условия условием использования своих компьютеров (я работаю в компании, которая работает в Европе, настраивая такие процессы мониторинга, хотя я работаю в подразделении, которое не занимается бизнесом в Европе), но могут найти ссылки, которые предполагают, что такие термины не являются незаконными, если они явные и прозрачные.

— Рэндалл

9

Я думаю, что этот вопрос был бы более уместным для security.stackexchange.com, где тема MITM обсуждается во многих вопросах. Но в любом случае:

Проверка сертификата сервера выполняется только на клиенте и не может быть каким-либо образом перемещена на сервер, поскольку точка проверки сертификата на клиенте заключается в том, что клиенты должны убедиться, что он обращается к правильному серверу и не может доверять (ненадежный) сервер, чтобы принять это решение для клиента.

В случае перехвата SSL клиентом TLS с точки зрения сервера является перехватывающий брандмауэр SSL / AV. Таким образом, проблема на стороне сервера состоит в том, чтобы определить, говорит ли он с ожидаемым клиентом (браузером) или нет (межсетевой экран / AV). Самый безопасный способ сделать это - использовать клиентские сертификаты для аутентификации клиента - и фактически перехват SSL не будет работать, если используется аутентификация клиента, то есть рукопожатие TLS не будет выполнено, поскольку MITM не может предоставить ожидаемый клиентский сертификат.

Только клиентские сертификаты используются редко. Кроме того, сбой квитирования TLS не означает, что клиент может взаимодействовать с сервером без перехвата SSL, но что клиент вообще не может взаимодействовать с сервером. Альтернативным способом было бы использование некоторой эвристики для обнаружения типа клиента TLS на основе отпечатка пальца рукопожатия TLS, то есть типа и порядка шифров, использования определенных расширений ... Хотя прокси-сервер, перехватывающий SSL, теоретически может эмулировать исходный ClientHello совершенно не так. См. Также « Обнаружение посредника на стороне сервера» для HTTPS или раздел III «Эвристика реализации TLS в воздействии безопасности при перехвате HTTPS» .

— Штеффен Ульрих
источник

14

Мне кажется, что работодатель использует свое превосходящее положение, чтобы шпионить за SSL-трафиком сотрудника. Для меня это делает всю концепцию SSL ненадежной

Проблема не в концепции SSL и не в технической реализации, а в том, что кто-то еще имеет полный контроль над одной конечной точкой соединения, то есть вашей рабочей станцией.
Это корень реальной угрозы безопасности ...

С точки зрения безопасности, ваша рабочая станция скомпрометирована, что разрушает цепочку доверия, которая в нормальных условиях препятствует успеху MITM.

Как я могу проверить цепочку доверия на стороне сервера?

Ты не можешь Это делается на стороне клиента.

В зависимости от вашего варианта использования, вы можете использовать закрепление открытого ключа RFC 7469 HTTP, в котором вы отправили клиенту дополнительный заголовок со списком (хэшей) ваших действительных сертификатов SSL или используемых вами CA.

— HBruijn
источник

4

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

— Штеффен Ульрих

2

Вы абсолютно правы в этом: §2.6 из RFC: «Допустимо разрешить проверку Pin для некоторых хостов в соответствии с локальной политикой. Например, UA может отключить проверку Pin для закрепленных хостов, цепочка проверенных сертификатов которых заканчивается на пользовательская привязка доверия, а не привязка доверия, встроенная в UA (или базовую платформу). "

— HBruijn

3

Это неправильный путь. Не сервер проверяет цепочку доверия. Это Клиент. Таким образом, причина, по которой компания использует этот способ, заключается в том, чтобы обеспечить безопасность компании и проверить, что сотрудник делает в свое рабочее время.

— beli3ver
источник

Ну, да, я знаю, что это, вероятно, не может быть предотвращено только на стороне сервера. Однако некоторые JS на стороне клиента также могут быть обмануты. Кстати, слежка за сотрудниками является незаконной в большинстве европейских стран. Как оператор веб-сайта, я хочу не допустить, чтобы мои клиенты были одурачены, поэтому я задаюсь вопросом, могу ли я каким-то образом проверить цепочку доверия безопасным способом.

— Aileron79

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

— beli3ver

Я понимаю вашу точку зрения. Тем не менее, этот вопрос о том, как я могу гарантировать, что соединение HTTPS зашифровано сквозным. Схема, которую я описал выше, очень распространена в корпоративных средах, но тот же тип атаки может использоваться ревнивыми мальчиками, чтобы шпионить за их подругами или домовладельцами, перехватывающими трафик своих арендаторов. Эти люди все еще должны быть обмануты в установке сертификата, но это простая часть. Тем не менее, это незаконно - и я все еще задаюсь вопросом, есть ли способ, которым я могу гарантировать, что соединение HTTPS действительно зашифровано e2e.

— Aileron79

3

Это невозможно. Когда корневой сертификат был изменен на клиенте, у вас нет возможности проверить его. Сервер не выполняет проверку, клиент делает проверку.

— beli3ver

3

Вы МОЖЕТЕ (вроде), но реальный вопрос в том, ДОЛЖНЫ ли вы .

Но будьте осторожны, это не так просто, как изменить флаг в apache.conf.

Кроме того, поскольку «злоумышленник» (например, работодатель) контролирует клиентский компьютер, они всегда могут помешать вашим попыткам, если они склонны вкладывать достаточно усилий (с другой стороны, если вы не очень крупная рыба, скорее всего, это не так). склонен, так что вы достигнете своей цели, что ваши пользователи не смогут подключиться к вам, если это не безопасно))

Вы можете переопределить TLS в javascript и проверить там, является ли сертификат, к которому подключен клиент, сертификатом вашего веб-сайта.
если вам повезет , пользователь может использовать браузер, где Javascript на стороне клиента может получить информацию об используемом удаленном сертификате (и, таким образом, легко проверить его по жестко заданному значению сертификата вашего сервера).
Вы можете использовать JavaScript для запуска вашего собственного шифрования . Таким образом, даже если злой TLS MiTM компании преуспел, он все равно не дал бы ей доступ к вашим данным. Конечно, если они достаточно заинтересованы (и поскольку они контролируют клиента), они могут просто на лету заменить ваш безопасный javascript своим собственным, который также регистрирует (или изменяет) всю передаваемую информацию.

Кроме того, поскольку компании, использующие прокси-серверы TLS MiTM, также обычно полностью контролируют клиентский компьютер, они могут легко установить экран и кейлоггер, чтобы просто записывать видео всего, что видит пользователь, и записывать все нажатия клавиш (и движения мыши), которые вводит пользователь. Как вы можете видеть, когда злоумышленник IS клиента, нет абсолютно безопасного способа обмануть его. Это действительно просто вопрос, насколько они будут беспокоить ... И некоторые из приведенных выше решений могут быть достаточно хорошими для вас.

— Матия Налис
источник

" Вы могли бы переопределить TLS в JavaScript " Как? Где?

— любопытный парень

@curiousguy, этот текст является ссылкой - нажмите на него, и он приведет вас к другому вопросу и ответу, и, наконец, к проекту digitalbazaar / Forge

— Матия Налис

Итак, когда это можно использовать? Для чего?

— любопытный парень

@curiousguy среди многих других вещей, особенно для целей, заданных в этом вопросе о Serverfault. Когда у вас есть собственный JS TLS, работающий на клиенте, этот клиент JS будет точно знать, к какому TLS-серверу был подключен клиент (и его открытый ключ). Затем вы можете сравнить этот открытый ключ с открытым ключом авторизованного сервера (также жестко заданным в вашем JS), и, если вы узнаете, совпадают ли они. Если они не совпадают, ваше соединение было взломано MiTM.

— Матия Налис