Нет, нужен не сертификат, а наличие другого сервиса с сертификатом, соответствующим атакуемому домену.Предположим, что я - админ bank.com, и у меня есть почтовый сервер, mx.bank.com. Я законным путём получил сертификат сразу на два домена: "bank.com" и "mx.bank.com". Или на *.bank.com. Или на почтовом сервере у меня используется тот же сертификат, что и на веб-сервере - любой из этих вариантов подойдёт для атакующего. Важно лишь то, что сертификат, которым пользуется mx.bank.com, годится и для bank.com.
Есть жертва. Она приходит в кафе поесть, но оказывается, что денег на карте не хватает, чтобы расплатиться, и приходится заходить на bank.com, чтобы перекинуть немного с накопительного счёта на карточный. Хорошо, что рядом есть wifi ap, ведь в этом месте мобильная сеть плохо работает.
И есть злоумышленник. Который поднял эту wifi ap. Он уже давно пытается перехватить сессию пользователей на bank.com. Сначала он просто заворачивал трафик на свой nginx, но админы настроили https, и пользователь пугается и закрывает браузер, видя большое красное предупреждение. Поэтому злоумышленник стал действовать хитрее. Он стал подсовывать жертве ссылку на свой сайт, который из js делает POST-запрос на https://bank.com/transfer.cgi?to=eviljoe123&amount=100500. Разработчики банка узнали про этот трюк, и стали в веб-формы вставлять случайные CSRF-токены, которые злоумышленник угадать не может, а в обработчике transfer.cgi проверять их наличие.
Теперь появилась вот эта новая атака. Злоумышленник подсовывает ссылку на evil.com/switchdns.cgi. Когда жертва переходит по ссылке, switchdns.cgi перенастраивает сеть так, чтобы трафик до bank.com попадал на mx.bank.com, а потом отдаёт редирект на bank.com/<script.../>. Браузер жертвы подключается туда (TLS), проверяет сертификат (с ним всё ок) и отправляет ничего не подозревающему почтовому серверу HTTP-запрос. Почтовый сервер отвечает "я не знаю, что такое <script.../>". Браузер интерпретирует это, как HTTP-ответ с тегом <script/> внутри, и начинает выполнять этот скрипт в контексте bank.com. А дальше злоумышленник возвращает всё обратно - пускает трафик по обычному пути до bank.com, а в своём скрипте делает запрос веб-формы, парсит оттуда CSRF-токен и делает POST на перевод денег - всё это из браузера пользователя, исполняющего его скрипт.
Нигде во время атаки злоумышленнику не нужно ни владеть никакими сертификатами, ни находиться в сговоре с админами bank.com.
