Здравствуйте! Я прошу прощения за осознанный оффтопик. Но, к сожалению, я вряд ли где еще найду столько людей понимающих как работает SPDY и HTTP/2, чем тут. К тому же проблема косвенно затрагивает конфигурирование nginx и, когда IPv6 станет более массовым с проблемой столкнется, мне кажется, большинство присутствующих.
Некоторое время назад я обнаружил и зарепортил следующий баг: https://bugzilla.mozilla.org/show_bug.cgi?id=1190136 Выглядело это как будто, обращаясь к одному виртуалхосту, я получаю контент другого. Конкретно понимание проблемы пришло тут https://bugzilla.mozilla.org/show_bug.cgi?id=1190136#c22 . Как вопроизвести, описано тут https://bugzilla.mozilla.org/show_bug.cgi?id=1190136#c19 Если кратко, то при использовании SPDY\HTTP/2 (для краткости SPDY) Firefox, начиная с вот этого коммита (https://hg.mozilla.org/mozilla-central/rev/5d7317e09ea1) принимает решение о повторном использовании соединения с виртуалхостом по протоколу IPv6 на основании совпадения адреса в A-записи при условии использования обоими wildcard-сертификата валидного для обоих виртуалхостов. То есть У нас есть домен example.com и сертификат *.example.com. На сервере и на клиентах должен быть функционирующий IPv6 (я на клиентах использую туннельного брокера). 1) Заводим два субдомена (например aaa.example.com и bbb.example.com), указывающих на одинаковый ipv4 адрес (A-запись) и разные ipv6 адреса (AAAA- запись) 2) В заводим два виртуальных хоста, можно на одном сервере, можно на разных. Главное, чтоб у них использовались субдомены из п.1, сертификат *.example.com, и IPv6 адреса соотвествовали AAAA-записям из п.1. IPv4 адреса тут не важны. 3) Пытаемся загрузить https://a.example.com. Файрфокс присылает запрос на правильный IPv6 адрес, проставляя правильное поле Host в запросе. 4) Пытаемся загрузиться https://b.example.com, файрфокс будет повторно использовать соединение из п.3, основываясь на том, что оба субдомена имеют одну и ту же A-запись. И пошлет запрос на IPv6 адрес первого домена, передав в заголовке Host адрес второго домена. Разработчик, отвественный за эту часть броузера сказал, что это не баг и чинить он его не будет. Посоветовав использовать разные сертификаты для разных субдоменов (а не wildcard) или пользоваться http-ответом с кодом 451. Однако я с этим в корне не согласен, более того, считаю, что такое поведение открывает уязвимость, которую я описал тут: https://bugzilla.mozilla.org/show_bug.cgi?id=1190136#c22 Но технической квалификации и политического веса в мире броузеров и серверов мне не хватает. Так же мало кто используется ipv6 на клиенте, поэтому массовка еще набралась. Что я хочу, написав, это письмо здесь? 1) Оцените, пожалуйста, насколько я прав. Может быть все не так, как мне кажется? Дальше только, если я прав. 2) Помогите найти аргументы для убеждения разработчиков ФФ, что этот баг надо исправлять. Если кто готов отписаться там, я открою обратно этот баг. 3) Может быть как-то можно сконфигурировать nginx, чтобы решить эту проблему, кроме использования раздельных сертификатов для поддоменов? Ибо раздельные сертификаты - не всегда возможно. Спасибо за помощь. С уважением, Иван Прокудин.
_______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
