SSL и непонимание вручную

Ответ 1

Атаки "Человек-в-середине" на SSL действительно возможны только в случае нарушения одного из предварительных условий SSL, вот несколько примеров:

• Ключ сервера был украден - это означает, что злоумышленник может быть сервером, и клиент не может знать.

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

• Клиент не утруждает себя правильной проверке сертификата против своего списка доверенных ЦС - любой может создать ЦС. Без подтверждения, "Ben Cars and Certificates" будет выглядеть так же корректно, как Verisign.

• Клиент подвергся атаке, и поддельный ЦС был введен в его доверенные корневые органы - позволяет злоумышленнику генерировать любой сертификат, который ему нравится, и клиент будет ему доверять. Вредоносная программа имеет тенденцию делать это, например, перенаправлять вас на поддельные банковские сайты.

Особенно # 2 довольно противно, даже если вы платите за высоконадежный сертификат, ваш сайт никоим образом не будет заблокирован для этого сертификата, вы должны доверять всем ЦС в клиентском браузере, поскольку любой из них может генерировать поддельный сертификат для вашего сайта, который так же важен. Он также не требует доступа ни к серверу, ни к клиенту.

Ответ 2

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

Сервер отвечает цепочкой сертификатов X.509 и цифровой подписью, подписанной своим личным ключом.

Затем клиент принимает решение, если доверяет серверу

Правильно.

шифрует некоторый случайный ключ сеанса с открытым ключом и отправляет его обратно.

Нет. Клиент и сервер участвуют в процессе генерации ключа сеанса, в котором сам сеансовый ключ никогда не передается вообще.

Этот ключ сеанса может быть дешифрован только с закрытым ключом, хранящимся на сервере.

Нет.

Сервер делает это

Нет.

а затем начинается сеанс HTTPS.

Начало сеанса TLS/SSL, но сначала выполняется несколько шагов.

Итак, если я верю выше, возникает вопрос, как может произойти атака "человек в середине" в таком сценарии?

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

Я имею в виду, что даже если кто-то перехватывает ответ сервера (например, www.server.com) с открытым ключом, а затем некоторыми средствами позволяет мне думать, что он www.server.com, он все равно не сможет расшифровать мой ключ сеанса без закрытого ключа.

См. выше. Для дешифрования ключ сеанса отсутствует. Само соединение SSL безопасно, и тот, с кем вы разговариваете, может быть небезопасным.

Говоря о взаимной аутентификации, все дело в уверенности сервера в идентификации клиента? Я имею в виду, что клиент уже может быть уверен, что она общается с правильным сервером, но теперь сервер хочет узнать, кто является клиентом, правильно?

Правильно.

И последний вопрос касается альтернативы взаимной аутентификации. Если я буду выступать в качестве клиента в описанной ситуации, что, если я отправлю логин/пароль в HTTP-заголовке после установления сеанса SSL? Как я вижу, эта информация не может быть перехвачена, поскольку соединение уже защищено, и сервер может полагаться на него для моей идентификации. Я не прав?

Нет.

Каковы недостатки такого подхода в сравнении с взаимной аутентификацией (важны только проблемы безопасности, а не сложность реализации)?

Он безопасен только как имя пользователя/пароль, которые намного легче утечка, чем закрытый ключ.

Ответ 3

Любой, кто находится на пути между клиентом и сервером, может поставить человека в середине атаки по https. Если вы считаете, что это маловероятно или редко, учтите, что существуют коммерческие продукты, которые систематически дешифруют, сканируют и повторно шифруют весь трафик ssl через интернет-шлюз. Они работают, отправляя клиенту сертификат ssl, созданный на лету, с подробностями, скопированными из "настоящего" сертификата ssl, но подписанными с помощью другой цепочки сертификатов. Если эта цепочка заканчивается каким-либо из доверенных ЦС браузера, этот MITM будет невидим для пользователя. Эти продукты в основном продаются компаниям для "защищенных" (полицейских) корпоративных сетей и должны использоваться с ведома и согласия пользователей. Технически, однако, ничто не мешает их использованию интернет-провайдерами или любым другим сетевым оператором. (Было бы безопасно предположить, что у АНБ есть хотя бы один ключ подписи доверенного корневого СА).

Если вы обслуживаете страницу, вы можете включить заголовок HTTP, указывающий, с каким открытым ключом должна быть подписана страница. Это может помочь предупредить пользователей MITM об их "безопасном" соединении, но это метод доверия при первом использовании. Если у Боба еще нет записи "реального" вывода открытого ключа, Мэллори просто переписывает заголовок pkp в документе. Список веб-сайтов, использующих эту технологию (HPKP), удручающе короток. Это включает в себя Google и Dropbox, к их кредиту. Обычно шлюз, перехватывающий https, будет перебирать страницы с нескольких крупных надежных сайтов, использующих HPKP. Если вы видите ошибку HPKP, когда вы ее не ожидаете, будьте осторожны.

Что касается паролей, все в соединении https защищено https, кроме имени домена, которое должно быть в открытом виде, чтобы запрос мог быть перенаправлен. В общем, рекомендуется не помещать пароли в строку запроса, где они могут зависать в журналах, закладках и т.д. Но строка запроса не отображается, если https не скомпрометирован.

Ответ 4

• Правильно
• Не так правильно. При такой атаке сервер itermediate получает ваш запрос и отправляет его в пункт назначения от вашего имени. и затем ответьте на результат. На самом деле это сервер "человек-в-середине", который обеспечивает безопасное соединение с вами, а не с фактическим сервером, с которым вы собираетесь общаться. поэтому вы ДОЛЖНЫ всегда проверять достоверность и достоверность сертификата.
• может быть правильным
• Если вы уверены, что защищенное соединение надежно, тогда будет безопасно отправлять имя пользователя/пароль.

Ответ 5

Все, что вы сказали, правильно, за исключением части о сеансовом ключе. Точка СА - это победить атаку "человек в середине" - все остальное делается самим SSL. Аутентификация клиента является альтернативой схеме имени пользователя и пароля.

Ответ 6

У меня вопрос по 1 способу SSL и способу проверки подлинности серверов клиентом. Если Клиент аутентифицирует только корневой или промежуточный CA, а не фактический сертификат, может ли любая другая сторона, имеющая сертификат, выданный тем же CA, быть аутентифицирована клиентом? Например, если соединение происходит от клиента A к серверу C, где у сервера C есть сертификат, выданный CA1, может ли злоумышленник B, имеющий другой сертификат, но выданный тем же CA1, быть аутентифицирован клиентом A?