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