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