Re: Firefox повторно исплользует соединение IPv6 на основании IPv4. Как с этим жить?

[Maxim Dounin]

Hello!

On Wed, Jun 01, 2016 at 11:10:36PM +0300, Иван wrote:

> В письме от 1 июня 2016 22:15:24 пользователь Maxim Dounin написал:
> 
> > Т.е. проблема в том, что Firefox пытается делать connection reuse
> > для всех IP-адресов двух хостов, если у этих хостов хотя бы один
> > общий IP-адреса?
> 
> Да. Если у хостов общий IPv4, то FF делает reuse и для IPv6, который в свою 
> очередь может различаться. Как по моему это против всякой логики, но вот 
> некоторые трактуют RFC именно так (см. ниже).

Отмечу, что стоит редуцировать ту же задачу для двух IPv4 адресов 
(точнее, трёх: один общий и два уникальных), и дальше обсуждать 
уже её.  Присутствие IPv6, насколько я понимаю, не важно, и только 
затрудняет понимание проблемы.

> > Это выглядит как нарушение стандарта.  RFC 7540 говорит нам, что
> > reuse возможен только в том случае, если хост резолвится в тот же
> > IP-адрес, к которому установлено существующее соединение
> > (https://tools.ietf.org/html/rfc7540#section-9.1.1):
> > 
> >    A connection can be reused as long as the origin server
> >    is authoritative (Section 10.1).  For TCP connections without TLS,
> >    this depends on the host having resolved to the same IP address.
> >
> 
> Ну насколько я понял логику Patrick McManus (разработчика, который не хочет это 
> править), он понимает этот абзац как "если хост резолвится в одинаковый IP адрес 
> (в одной из версий IP), то можно делать reuse (во всех остальных версиях)".

Сказано - "a connection".  Т.е. host резолвится в тот же IP-адрес, 
к которому установлено существующее соединение.  Понимать это 
можно как угодно, но любое другое понимание не соответствует тому, 
что написано.

> > > Однако я с этим в корне не согласен, более того, считаю, что такое
> > > поведение открывает уязвимость, которую я описал тут:
> > > https://bugzilla.mozilla.org/show_bug.cgi?id=1190136#c22
> > > Но технической квалификации и политического веса в мире броузеров и
> > > серверов мне не хватает. Так же мало кто используется ipv6 на клиенте,
> > > поэтому массовка еще набралась.
> > 
> > Уязвимости тут как таковой нет: без SSL/TLS Firefox не умеет
> > HTTP/2, а для connection reuse в случае TLS нужно ещё, чтобы был
> > представлен корректный сертификат, покрывающий оба доменных имени.
> 
> Ну значит уязвимость теоретическая. Если по какой-то причине будет возможен 
> HTTP/2 без SSL/TLS, то можно будет использовать эту уязвимость.

Безусловно.  И это лишний раз подтверждает, что вышеозначенное 
"понимание" неверно.

[...]

> > > 2) Помогите найти аргументы для убеждения разработчиков ФФ, что этот баг
> > > надо исправлять. Если кто готов отписаться там, я открою обратно этот
> > > баг.
> > См. аргументы выше.  На лицо явное нарушение стандарта.
> > 
> 
> Если б всё было так просто, поверьте, я бы не отнимал Ваше время.

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

> >     server {
> >         listen [2001:db8::1]:443 ssl http2 default_server;
> >         listen [2001:db8::2]:443 ssl http2 default_server;
> >         return 421;
> >     }
> > 
> > Для Firefox'а этого должно быть достаточно, чтобы переоткрыть
> > соединение.
> >
> 
> Спасибо. Это похоже то, что нужно. Нужно ли для этого обновляться до 1.11.0 или 
> 
> Change: the "421 Misdirected Request" response now used when
>        rejecting requests to a virtual server different from one negotiated
>        during an SSL handshake; this improves interoperability with some
>        HTTP/2 clients when using client certificates.
> 
> не про это?

Обновляться не обязательно - вернуть руками можно в любой версии.  
При этом к коду ответа и не будет прилагаться красивого сообщения 
об ошибке, но это не особо важно, т.к. это ошибка предназначена 
для автоматической обработки браузером, а не для демонстрации 
пользователям.

Процитированное изменение - оно тоже про борьбу с connection 
reuse, но в части использования клиентских сертификатов 
(http://trac.nginx.org/nginx/ticket/848).

-- 
Maxim Dounin
http://nginx.org/