Непонимание SSL и посредника

Я прочитал массу документации, связанной с этой проблемой, но все еще не могу собрать все воедино, поэтому я хотел бы задать пару вопросов.

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

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

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

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

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

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

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

• Клиент не заботится о том, чтобы правильно проверить сертификат по списку доверенных центров сертификации - любой может создать центр сертификации. Без проверки «Машины и сертификаты Бена» будут иметь такую ​​же силу, как и Verisign.

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

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

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

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

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

Верный.

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

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

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

Нет.

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

Нет.

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

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

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

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

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

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

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

Верный.

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

Нет.

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

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

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

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

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

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

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