Apache: проверять цепочку доверия SSL для предотвращения MITM-атак?
Я только что понял, что атаки типа "человек посередине" SSL встречаются гораздо чаще, чем я думал, особенно в корпоративных средах. Я слышал и видел несколько предприятий, у которых есть прозрачный прокси-сервер SSL. Все клиенты настроены доверять сертификату этого прокси. Это в основном означает, что работодатель теоретически может перехватывать даже зашифрованный трафик SSL без каких-либо предупреждений в браузере. Как упомянуто выше, клиенты идут с доверенным сертификатом. Это можно выявить только путем ручной проверки используемого сертификата.
Мне кажется, что работодатель использует свое превосходящее положение, чтобы шпионить за SSL-трафиком сотрудника. Для меня это делает всю концепцию SSL ненадежной. Я успешно протестировал подобную настройку, используя mitmproxy, и смог прочитать связь между клиентом и моим сервером электронного банкинга. Это информация, которую никто не должен раскрывать.
Таким образом, мой вопрос довольно прост: как я могу проверить цепочку доверия на стороне сервера? Я хочу убедиться, что клиент использует сертификат моего сервера и только одну цепочку доверия. Интересно, может ли это быть достигнуто с помощью конфигурации Apache SSL? Это было бы удобно, так как его можно легко применить ко многим приложениям. Если это невозможно, кто-нибудь знает способ сделать это в PHP? Или у вас есть другие предложения?
4 ответа
Я думаю, что этот вопрос был бы более уместным для https://security.stackexchange.com/, где тема MITM обсуждается во многих вопросах. Но в любом случае:
Проверка сертификата сервера выполняется только на клиенте и не может быть каким-либо образом перемещена на сервер, поскольку точка проверки сертификата на клиенте заключается в том, что клиенты должны убедиться, что он обращается к правильному серверу и не может доверять (ненадежный) сервер, чтобы принять это решение для клиента.
В случае перехвата SSL клиентом TLS с точки зрения сервера является перехватывающий брандмауэр SSL /AV. Таким образом, проблема на стороне сервера состоит в том, чтобы определить, говорит ли он с ожидаемым клиентом (браузером) или нет (брандмауэр /AV). Самый безопасный способ сделать это - использовать клиентские сертификаты для аутентификации клиента - и фактически перехват SSL не будет работать, если используется аутентификация клиента, то есть рукопожатие TLS не будет выполнено, так как MITM не может предоставить ожидаемый клиентский сертификат.
Только клиентские сертификаты используются редко. Кроме того, сбой квитирования TLS не будет означать, что клиент может общаться с сервером без перехвата SSL, но что клиент вообще не может связаться с сервером. Альтернативным способом было бы использование некоторой эвристики для определения типа клиента TLS на основе отпечатка пальца рукопожатия TLS, то есть типа и порядка шифров, использования определенных расширений... Хотя прокси-сервер, перехватывающий SSL, теоретически может эмулировать исходный ClientHello совершенно не так. См. Также " Обнаружение посредника на стороне сервера" для HTTPS или раздел III "Эвристика реализации TLS в влиянии безопасности на перехват HTTPS".
Мне кажется, что работодатель использует свое превосходящее положение, чтобы шпионить за SSL-трафиком сотрудника. Для меня это делает всю концепцию SSL ненадежной
Проблема не в концепции SSL и не в технической реализации, а в том, что кто-то еще имеет полный контроль над одной конечной точкой соединения, то есть вашей рабочей станцией.
Это корень фактической угрозы безопасности...
С точки зрения безопасности, ваша рабочая станция скомпрометирована, что разрушает цепочку доверия, которая в нормальных условиях препятствует успеху MITM.
Как я могу проверить цепочку доверия на стороне сервера?
Ты не можешь Это делается на стороне клиента.
В зависимости от вашего варианта использования, вы можете использовать закрепление открытого ключа RFC 7469 HTTP, в котором вы отправили клиенту дополнительный заголовок со списком (хешами) ваших действительных сертификатов SSL или используемых вами ЦС.
Это неправильный путь. Не сервер проверяет цепочку доверия. Это Клиент. Таким образом, причина, по которой компания использует этот способ, заключается в том, чтобы обеспечить безопасность компании и проверить, что сотрудник делает в свое рабочее время.
Вы МОЖЕТЕ (вроде), но реальный вопрос в том, ДОЛЖНЫ ли вы.
Но будьте осторожны, это не так просто, как изменить флаг в apache.conf.
Кроме того, поскольку "злоумышленник" (например, работодатель) контролирует клиентский компьютер, они всегда могут помешать вашим попыткам, если они склонны вкладывать достаточно усилий (с другой стороны, если вы не очень крупная рыба, скорее всего, это не так). склонен, так что вы достигнете своей цели, что ваши пользователи не смогут подключиться к вам, если это не безопасно))
Вы можете переопределить TLS в javascript и выполнить там проверку, если сертификат, к которому подключен клиент, является сертификатом вашего веб-сайта.
если вам повезет, пользователь может использовать браузер, где Javascript на стороне клиента может получить информацию об используемом удаленном сертификате (и, таким образом, легко проверить его по жестко заданному значению сертификата вашего сервера).
Вы можете использовать JavaScript для запуска вашего собственного шифрования. Таким образом, даже если злой TLS MiTM компании преуспел, он все равно не дал бы ей доступ к вашим данным. Конечно, если они достаточно заинтересованы (и поскольку они контролируют клиента), они могут просто на лету заменить ваш безопасный javascript своим собственным, который также регистрирует (или изменяет) всю передаваемую информацию.
Кроме того, поскольку компании, использующие прокси-серверы TLS MiTM, также обычно полностью контролируют клиентский компьютер, они могут легко установить экран и кейлоггер, чтобы просто записывать видео всего, что видит пользователь, и записывать все нажатия клавиш (и движения мыши), которые вводит пользователь. Как вы можете видеть, когда злоумышленник является клиентом, не существует абсолютно безопасного способа обмануть его. Это действительно просто вопрос, насколько они будут беспокоить... И некоторые из приведенных выше решений могут быть достаточно хорошими для вас.