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

91

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

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

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

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

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

Вадим Чекрый
источник

Ответы:

106

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

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

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

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

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

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

Иоахим Исакссон
источник
4
Также существуют такие инструменты, как sslstrip , которые будут пытаться прозрачно переписать https-ссылки в http-ссылки.
mpontillo
3
Еще один момент, связанный с проверкой сертификата, заключается в том, что клиенту необходимо проверить имя хоста. Недостаточно проверять подлинность сертификата, это должно быть проблемой для объекта, с которым вы хотите поговорить (см. Здесь и здесь ). Что касается sslstrip, то в конечном итоге пользователь должен убедиться, что, к сожалению, он хочет использовать SSL / TLS (хотя HSTS может помочь).
Бруно
Могу ли я написать плагин для Chrome (или любого другого браузера, если на то пошло), который перехватывает данные ДО того, как браузер их зашифрует?
Росди Касим
Другая причина - «злоупотребление доверием», как в вопросе TürkTrust.
ceremcem
1
@Remover Не совсем ... №1 - это закрытый ключ на сервере в паре с настоящим открытым ключом. В этом сценарии вы разговариваете с реальным сервером, но кто-то другой может расшифровать трафик, находясь посередине. Они не могут изменить сертификат. №2 включает отправку совершенно другого сертификата, выпущенного «доверенным» центром сертификации, который будет казаться клиенту легитимным. Затем злоумышленник может отправлять запросы от вашего имени и таким образом просматривать сообщения. Оба приводят к компромиссу, но №1 находится под вашим контролем. №2, к сожалению, нет.
Basic
17

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

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

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

Верный.

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

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

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

Нет.

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

Нет.

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

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

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

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

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

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

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

Верный.

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

Нет.

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

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

Маркиз Лорн
источник
Спасибо за ваше объяснение. Единственное, что я не понял, это почему вы сказали, что клиент не отправляет сеансовый ключ на сервер? Что ж, может быть, я использовал неправильную терминологию, здесь этот фрагмент данных называется «pre-master secret», но в любом случае, разве он не отправляется клиентом и не расшифровывается с помощью закрытого ключа сервера?
Вадим Чекрий
1
@VadimChekry Предварительный секретный ключ не является сеансовым ключом. Это один из нескольких фрагментов данных, используемых для генерации сеансового ключа независимо на обоих концах. Процесс описан в RFC 2246.
Marquis of Lorne
1
@Chris Вы гораздо менее уязвимы, однако возможна подмена IP-адреса. Самостоятельная проверка идентичности однорангового узла в сертификате ничем не заменит.
Маркиз Лорн,
1
+1 Это по большей части неплохой ответ. Однако некоторым пунктам не хватает объяснения с помощью односложных ответов. Вы могли бы дать окончательный ответ, если бы вы расширили и / или уточнили упомянутые моменты (т.е. вместо «нет» вы могли бы кратко упомянуть, что на самом деле происходит.) В основной части. Это действительно прояснило бы несколько вещей. Спасибо.
голоса
1
@ tjt263 Первое «нет» объясняет, что происходит на самом деле. Следующие два «нет» относятся к тому же заблуждению, которое привело к первому «нет», и имеют такое же объяснение. Следующее и последнее «нет» относится к «я ошибаюсь» и относится к информации, только что процитированной из OP. Поэтому трудно понять то, чего, по вашему мнению, здесь действительно не хватает.
Маркиз Лорн,
17

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

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

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

bbsimonbb
источник
Но это означает, что это оборудование MITM (то, которое расшифровывает / сканирует и повторно шифрует трафик) должно иметь доступ к одному из доверенных центров сертификации, верно? (чтобы «подделать» сертификат сервера). Допустим, это случается. Затем кто-то это нарушит, информация станет общедоступной, и в прессе будет скандал, и сертификат CA будет удален из всех браузеров, верно? Я имею в виду, в идеале ...
jazzcat
2
Нет нет. «Проверка SSL» на шлюзе требует создания и подписи сертификатов на лету, но для этого не требуется корневой сертификат. У него есть промежуточный сертификат, у которого есть цепочка. Независимо от того, доверяет ли корень цепочки ваш браузер, определяет, увидите ли вы ошибку сертификата. На работе нас попросили установить корневой сертификат fortinet, чтобы наши браузеры не выдавали ошибок сертификата. Но если цепочка завершилась уже доверенным сертификатом, это прозрачно.
bbsimonbb
Коллега по работе использовал ограниченное понимание того, почему эти методы MITM корпоративной сети - плохая идея для Google, чтобы принудительно использовать SSL. Может ли он на самом деле хоть немного править?
EmSixTeen 03
1
Извините, я не понимаю вопроса!
bbsimonbb 03
2
  1. Верный
  2. Не совсем так. В такой атаке промежуточный сервер получает ваш запрос и отправляет его по назначению от вашего имени. а затем ответим вам с результатом. На самом деле это сервер типа "человек посередине", который делает безопасное соединение с вами, а не с фактическим сервером, с которым вы должны общаться. поэтому вы ДОЛЖНЫ всегда проверять, что сертификат действителен и заслуживает доверия.
  3. может быть правильно
  4. Если вы уверены, что защищенное соединение является доверенным, тогда можно безопасно отправить имя пользователя и пароль.
Boynux
источник
Примерно 2 - я предполагаю, что клиент тщательно проверяет метаданные, отправленные сервером во время процедуры установления соединения, и что клиент не доверяет ВСЕМ сертификатам. Разве такой сценарий не был бы возможен, если: а) клиент не делает то, что я сказал выше, или б) посредник где-то получил сертификат, подписанный доверенным центром сертификации?
Вадим Чекрий
1
Очень редко промежуточный сервер отправляет действующий сертификат, в прошлом году это случилось с Comodo CA, если я хорошо помню. Но обычно, если это надежное соединение, оно полностью безопасно.
Boynux
1

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

Дэвид Шварц
источник