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

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

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

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

• Клиент не утруждает себя правильной проверке сертификата против своего списка доверенных ЦС – любой может создать ЦС. Без подтверждения, «Автомобили и сертификаты Бена» будут выглядеть так же корректно, как Verisign.

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

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

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

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

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

Верный.

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

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

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

Нет.

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

Нет.

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

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

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

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

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

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

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

Верный.

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

Нет.

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

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

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

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

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

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

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