SSL и недоразумение "человек посередине"
Я прочитал тонны документации, связанной с этой проблемой, но я все еще не могу собрать все части вместе, поэтому я хотел бы задать пару вопросов.
Прежде всего, я кратко опишу процедуру аутентификации, насколько я ее понимаю, поскольку я могу ошибаться в этом отношении: клиент запускает соединение, на которое сервер отвечает комбинацией открытого ключа, некоторых метаданных и цифровой подписи доверенная власть. Затем клиент принимает решение, доверяет ли он серверу, шифрует некоторый случайный ключ сеанса открытым ключом и отправляет его обратно. Этот сеансовый ключ может быть расшифрован только с помощью закрытого ключа, хранящегося на сервере. Сервер делает это, и затем начинается сеанс HTTPS.
Итак, если я прав в приведенном выше вопросе, вопрос в том, как может произойти атака "человек посередине" в таком сценарии? Я имею в виду, что даже если кто-то перехватит ответ сервера (например, www.server.com) с открытым ключом и найдет способ заставить меня думать, что он www.server.com, он все равно не сможет расшифровать мой сеансовый ключ. без закрытого ключа.
Говоря о взаимной аутентификации, все ли это связано с уверенностью сервера в идентичности клиента? Я имею в виду, что клиент уже может быть уверен, что он общается с нужным сервером, но теперь сервер хочет выяснить, кто клиент, верно?
И последний вопрос об альтернативе взаимной аутентификации. Если я действую как клиент в описанной ситуации, что если я отправлю логин / пароль в заголовке HTTP после установления сеанса SSL? На мой взгляд, эта информация не может быть перехвачена, поскольку соединение уже защищено, и сервер может использовать его для идентификации. Я ошибся? Каковы недостатки такого подхода по сравнению с взаимной аутентификацией (важны только вопросы безопасности, а не сложность реализации)?
5 ответов
Атаки "посредник" по SSL действительно возможны, только если нарушено одно из предварительных условий SSL, вот несколько примеров;
Ключ сервера был украден - значит, злоумышленник может оказаться сервером, и клиент не может знать об этом.
Клиент доверяет ненадежному ЦС (или тому, у которого был украден корневой ключ) - тот, кто владеет ключом доверенного ЦС, может сгенерировать сертификат, выдавая себя за сервер, и клиент будет доверять ему. С учетом того, что сегодня в браузерах уже существует количество CA, это может стать реальной проблемой. Это означает, что сертификат сервера может измениться на другой действительный сертификат, который большинство клиентов будет скрывать от вас.
Клиент не удосуживается правильно проверить сертификат по списку доверенных ЦС - любой может создать ЦС. Без проверки "Машины и сертификаты Бена" будут выглядеть так же, как и Verisign.
Клиент подвергся нападению, и в его доверенных корневых органах был введен поддельный ЦС - он позволяет злоумышленнику создать любой сертификат, который ему нравится, и клиент будет доверять ему. Вредоносные программы, как правило, делают это, например, чтобы перенаправить вас на поддельные банковские сайты.
Тем более, что № 2 довольно неприятный, даже если вы платите за сертификат с высоким доверием, ваш сайт никак не будет привязан к этому сертификату, вы должны доверять всем CA в браузере клиента, так как любой из них может создать поддельный сертификат для Ваш сайт, который так же действителен. Это также не требует доступа ни к серверу, ни к клиенту.
Любой, кто находится на пути между клиентом и сервером, может поставить человека в середине атаки по https. Если вы считаете, что это маловероятно или редко, учтите, что существуют коммерческие продукты, которые систематически дешифруют, сканируют и повторно шифруют весь трафик ssl через интернет-шлюз. Они работают, отправляя клиенту ssl-сертификат, созданный на лету, с подробностями, скопированными из "настоящего" ssl-сертификата, но подписанными с помощью другой цепочки сертификатов. Если эта цепочка оканчивается каким-либо из доверенных ЦС браузера, этот MITM будет невидим для пользователя. Эти продукты в основном продаются компаниям для "защищенных" (полицейских) корпоративных сетей и должны использоваться с ведома и согласия пользователей. Технически, однако, ничто не мешает их использованию интернет-провайдерами или любым другим сетевым оператором. (Было бы безопасно предположить, что у АНБ есть хотя бы один ключ подписи доверенного корневого СА)
Если вы обслуживаете страницу, вы можете включить заголовок HTTP, указывающий, с каким открытым ключом должна быть подписана страница. Это может помочь предупредить пользователей MITM об их "безопасном" соединении, но это метод доверия при первом использовании. Если у Боба еще нет записи "реального" вывода открытого ключа, Мэллори просто переписывает заголовок pkp в документе. Список сайтов, использующих эту технологию, удручающе короток. Это включает в себя Google и Dropbox, к их кредиту.
Что касается паролей, все в соединении https защищено https, кроме доменного имени, которое должно быть в открытом виде, чтобы запрос мог быть перенаправлен. Как правило, рекомендуется не помещать пароли в строку запроса, поскольку они могут зависать в журналах, закладках и т. Д. Но строка запроса не отображается, если https не скомпрометирован.
Прежде всего, я кратко опишу процедуру аутентификации, насколько я понимаю, возможно, я ошибаюсь на этом этапе. Таким образом, клиент устанавливает соединение, а сервер отвечает ему комбинацией открытого ключа, некоторых метаданных и цифровой подписи доверенного органа.
Сервер отвечает цепочкой сертификатов X.509 и цифровой подписью, подписанной собственным секретным ключом.
Затем клиент принимает решение, доверяет ли он серверу.
Правильный.
шифрует некоторый случайный ключ сеанса с помощью открытого ключа и отправляет его обратно.
Нет. Клиент и сервер участвуют в процессе генерации ключа сеанса, в результате чего сам ключ сеанса никогда не передается вообще.
Этот сеансовый ключ может быть расшифрован только с помощью закрытого ключа, хранящегося на сервере.
Нет.
Сервер делает это
Нет.
и затем начинается сеанс HTTPS.
Сеанс TLS/SSL начинается, но сначала нужно выполнить больше шагов.
Итак, если я прав в приведенном выше вопросе, вопрос в том, как атака "человек посередине" может происходить в таком сценарии?
Маскируясь под сервер и действуя как конечная точка SSL. Клиент должен будет пропустить любой шаг авторизации. К сожалению, единственный шаг авторизации в большинстве сеансов HTTPS - это проверка имени хоста.
Я имею в виду, что даже если кто-то перехватит ответ сервера (например, www.server.com) с открытым ключом, а затем с помощью некоторых средств позволит мне думать, что он www.server.com, он все равно не сможет расшифровать мой сеансовый ключ без закрытого ключа.
Смотри выше. Нет ключа сеанса для расшифровки. SSL-соединение само по себе является безопасным, это тот, с кем вы разговариваете, может быть небезопасно.
Говоря о взаимной аутентификации, все ли это связано с уверенностью сервера в идентичности клиента? Я имею в виду, что клиент уже может быть уверен, что он общается с нужным сервером, но теперь сервер хочет выяснить, кто является клиентом, верно?
Правильный.
И последний вопрос об альтернативе взаимной аутентификации. Если я действую как клиент в описанной ситуации, что если я отправлю логин / пароль в заголовке HTTP после установления сеанса SSL? Как я вижу, эта информация не может быть перехвачена, потому что соединение уже защищено, и сервер может использовать его для моей идентификации. Я ошибся?
Нет.
Каковы недостатки такого подхода по сравнению с взаимной аутентификацией (важны только вопросы безопасности, а не сложность реализации)?
Это так же безопасно, как имя пользователя / пароль, которые намного легче утечь, чем закрытый ключ.
- Правильный
- Не очень правильно. При такой атаке промежуточный сервер получает ваш запрос и отправляет его по назначению от вашего имени. а затем ответить вам с результатом. На самом деле это сервер типа "человек посередине", который делает защищенное соединение с вами не реальным сервером, к которому вы собираетесь подключиться. Вот почему вы ДОЛЖНЫ всегда проверять, является ли сертификат действительным и надежным.
- может быть правильным
- Если вы уверены, что защищенное соединение является доверенным, можно безопасно отправить имя пользователя / пароль.
Все, что вы сказали, правильно, кроме части о ключе сеанса. Цель СА - победить атаку "человек посередине" - все остальное делает сам SSL. Проверка подлинности клиента является альтернативой схеме имени пользователя и пароля.