kirill_782
@kirill_782
Днем я Маринетт

Почему нельзя расшифровать HTTPS?

Вопрос нуба:
Почему нельзя HTTPS трафик расшифровать? Как адресат понимает алгоритм деешифрования а тот кто перехватил нет. И возможно перехватить весь трафик чтобы расшифровать HTTPS?
  • Вопрос задан
  • 76 просмотров
Решения вопроса 1
CityCat4
@CityCat4
Жил да был CityCat за углом...
Слушайте больше тех, кто трет по ушам за то, что https нельзя расшифровать. "Что сделано одним человеком, завсегда другой может разломать" (С)
Сертификат состоит из двух частей - собственно сертификата и ключа. Сертификат рассылается всем подряд, его рассылка безопасна. Им шифруют. Ключ должен хранится в секрете, утечка ключа - полная компроментация сертификата. Им расшифровывают.
Защита https соединения основана на доверенных сертификатах. Когда Алиса хочет установить соединение с Бобом, она отправляем ему свой сертификат. Боб соответственно отправляет свой. И сейчас они уже могли бы установить соединение и сгенерить сессионный ключ, но возникает вопрос - а как Алиса удостоверится, что полученный ею сертификат принадлежит Бобу, а не хакеру Джону?
Скажу сразу - путей убедиться в том, что сертификат принадлежит Бобу, основываясь только на сертификате - нет. Нужно либо использовать предварительно согласованный ключ, если Алиса и Боб когда-то встречались раньше, либо обратиться к некоему арбитру, доверие к которому абсолютно ("командир сказал - хорек! И никаких сусликов!"). Если арбитр подтверждает, что этот сертификат принадлежит Бобу - значит так оно и есть.
И вот тут на сцену выступают доверенные корневые центры аутентификации. Это перечень арбитров, которые являются "абсолютной истиной" для данной системы. Если один из них, причем неважно какой сказал "это сертификат Боба" - система считает, что это сертификат Боба и переходит к генерации уникального сессионного ключа, который в теории не должен быть известен никому, кроме Боба. Не зная этого ключа соединение действительно расшифровать невозможно.
Но "хитер демон в Аппсале, а Язон динАльт хитрее". Хакер Джон развертывает у себя удостоверяющий центр и убеждает/заставляет каким-нибудь образом установить сертификат своего CA в корневые. Что происходит после этого? А то, что любой сертификат, выпущенный хакером Джоном - будет считаться доверенным!
Теперь Джону нужно "всего лишь" перехватить начальный пакет соединения Алисы к Бобу (не пропуская его к Бобу, конечно же). Джон выпускает себе сертификат с тем адресом, на который обратилась Алиса, а система Алисы посчитает этот сертификат доверенным - ведь он выпущен СA Джона, который у нее доверенный! Алиса установит соединение с Джоном, предполагая, что это Боб и отдаст ему сессионный ключ. Джон просмотрит урл, куда обратилась Алиса и, если ему это неинтересно, то он просто пропустит соединение через себя - отдаст сессионный ключ Бобу и дальше в соединение не вмешивается. Этот режим называется splice. Если же ему интересно, о чем там собираются они пообщаться, он инициирует соединение от своего имени, используя сессионный ключ Алисы и в дальнейшем так и сидит посередине, передавая пакеты справа налево и наоборот. Этот режим называется peek.
Это классическая атака Man-in-the-Middle (человек посередине) и она применяется в любом прокси squid с включенным режимом бампинга.
Остается только один вопрос - а как же Джон заставит Алису поставить сертификат своего СA в доверенные? Ну, здесь есть как минимум два варианта
1. Алиса - сотрудник конторы, а Джон - ее директор и хочет знать, куда ходят его подчиненные в рабочее время. Поэтому он наряжает админов сделать так, чтобы сертификат конторского CA у всех стоял в доверенных. Это стандартный сценарий в любой мало-мальски крупной конторе.
2. "Джон" является госструктурой, которую нарядили контролировать куда ходят граждане и она обязует всех провайдеров просто не пускать никуда, если на компе не стоит сертификата CA от "Джона". Это уже в реале сделано в Казахстане и скоро будет и в России.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через TM ID
Похожие вопросы