37 ответов в этой теме

[Alexander Chinyakov]

Итак, ситуация выглядит следующим образом:

[09/08/2017 16:06:11 0000073c] <DEBUG:2> - SEND/S 16="GET / HTTP/1.0\0d\0a"
[09/08/2017 16:06:11 0000073c] <DEBUG:2> - SEND/S 30="User-Agent: Wget/1.12 (msys)\0d\0a"
[09/08/2017 16:06:11 0000073c] <DEBUG:2> - SEND/S 13="Accept: */*\0d\0a"
[09/08/2017 16:06:11 0000073c] <DEBUG:2> - SEND/S 19="Host: www.yota.ru\0d\0a"
[09/08/2017 16:06:11 0000073c] <DEBUG:2> - SEND/S 24="Connection: Keep-Alive\0d\0a"
[09/08/2017 16:06:11 0000073c] <DEBUG:2> - SEND/S 2="\0d\0a"
[09/08/2017 16:06:11 0000073c] <DEBUG:2> - RECV/S 32="HTTP/1.1 301 Moved Permanently\0d\0a"
[09/08/2017 16:06:11 0000073c] <DEBUG:2> - RECV/S 32="Location: https://www.yota.ru/\0d\0a"
[09/08/2017 16:06:11 0000073c] <DEBUG:2> Server disconnected, error=00000000
[09/08/2017 16:06:11 0000073c] <DEBUG:2> Server closed the connection
[09/08/2017 16:06:11 0000073c] <DEBUG:2> - SEND/C 32="HTTP/1.1 301 Moved Permanently\0d\0a"
[09/08/2017 16:06:11 0000073c] <DEBUG:2> Shutdown: Client, SD_BOTH

Здесь в ответе сервера (RECV/S) две строки: статус и первый заголовок. Пустой строки, отделяющей заголовки от контента (в данном случае пустого) нет -- сразу идет обрыв соединения.

 

Стандарт же описывает структуру сообщения следующим образом (ссылка):

     HTTP-message   = start-line
                      *( header-field CRLF )
                      CRLF
                      [ message-body ]

[SergSG]

Итак, ситуация выглядит следующим образом:

Здесь в ответе сервера (RECV/S) две строки: статус и первый заголовок. Пустой строки, отделяющей заголовки от контента (в данном случае пустого) нет -- сразу идет обрыв соединения.

А что из этого следует?

[Alexander Chinyakov]

 

Итак, ситуация выглядит следующим образом:

Здесь в ответе сервера (RECV/S) две строки: статус и первый заголовок. Пустой строки, отделяющей заголовки от контента (в данном случае пустого) нет -- сразу идет обрыв соединения.

А что из этого следует?

 

Из этого следует то, что мы недополучили сообщение и undefined behaviour.

[SergSG]

Из этого следует то, что мы недополучили сообщение и undefined behaviour.

Что недополучили понятно, а без Гейта вроде бы как работает.

[v.martyanov]

 

Из этого следует то, что мы недополучили сообщение и undefined behaviour.

Что недополучили понятно, а без Гейта вроде бы как работает.

 

Браузеры и wget работают на раз, эт факт.

[basid]

Здесь в ответе сервера (RECV/S) две строки: статус и первый заголовок. Пустой строки, отделяющей заголовки от контента (в данном случае пустого) нет -- сразу идет обрыв соединения.
 
Стандарт же описывает структуру сообщения следующим образом (ссылка):

Вы педантичны там, где должны быть толерантны. Если соединение закрыто - сообщение завершено: пункт пять раздела 4.4

Сообщение было изменено basid: 09 Август 2017 - 20:01

[Alexander Chinyakov]

 

Здесь в ответе сервера (RECV/S) две строки: статус и первый заголовок. Пустой строки, отделяющей заголовки от контента (в данном случае пустого) нет -- сразу идет обрыв соединения.
 
Стандарт же описывает структуру сообщения следующим образом (ссылка):

Вы педантичны там, где должны быть толерантны. Если соединение закрыто - сообщение завершено: пункт пять раздела 4.4

 

 

Весь раздел 4.4 освещает нюансы относительно размера message-body, а здесь только заголовки передаются (разделитель еще не получен). Но насчет педантичности соглашусь :-)

[SergSG]

А все же непонятно - "был ли мальчик"?

[basid]

Весь раздел 4.4 освещает нюансы относительно размера message-body, а здесь только заголовки передаются (разделитель еще не получен)

Согласитесь, что нехорошо "глотать" последнюю строку заголовка, если она непустая. Особенно - педанту

[basid]

А все же непонятно - "был ли мальчик"?

"Он есть".
HTTP-сервер Yota (коряво) присылает две строки вместо трёх (отсутствует пустая строка-разделитель):

[09/08/2017 16:06:11 0000073c] <DEBUG:2> - RECV/S 32="HTTP/1.1 301 Moved Permanently\0d\0a"
[09/08/2017 16:06:11 0000073c] <DEBUG:2> - RECV/S 32="Location: https://www.yota.ru/\0d\0a"

Netfilter "отдаёт" клиенту только одну (безусловно "выкусывая" последнюю строку):

[09/08/2017 16:06:11 0000073c] <DEBUG:2> - SEND/C 32="HTTP/1.1 301 Moved Permanently\0d\0a"

[Alexander Chinyakov]

Я уже писал про неопределенное поведение (undefined behaviour): здесь мы не[до]получили ответ сервера, а согласно настройкам мы должны его еще и проверить. Если в сообщении вредоносное программное обеспечение -- ответ 301 предполагает, что там может быть контент, -- то мы должны вообще заблокировать, а для этого и статус другой нужен.

 

Над решением думаю.

Сообщение было изменено Alexander Chinyakov: 10 Август 2017 - 14:11

[basid]

Над решением думаю.

Согласитесь, что в данном конкретном случае блокировки не будет, но не отдать последнюю строку заголовка - неправильно в любом случае. Если мы педантично чтим rfc, то подходящий статус - 502 (Bad gateway) и у вас есть формальное оправдание: возвращён неполный ответ.

Сразу бросаться проверять Location - тоже не самое лучшее решение. С моей кочки зрения правильным будет сделать "быструю проверку, не требующую выхода в тыртырнет". Если результат "быстрой проверки" отрицательный (родительский/офисный контроль или "известные рассадники") - возвращаем "403 Ферботтен". Если положительный - возвращаем исходный ответ (возможно подкорректировав на формальную корректность) и начинаем остальные проверки тогда, когда UA сделает переход на Location.

Сообщение было изменено basid: 10 Август 2017 - 14:34

[Alexander Chinyakov]

 

Над решением думаю.

Согласитесь, что в данном конкретном случае блокировки не будет, но не отдать последнюю строку заголовка - неправильно в любом случае. Если мы педантично чтим rfc, то подходящий статус - 502 (Bad gateway) и у вас есть формальное оправдание: возвращён неполный ответ.

Сразу бросаться проверять Location - тоже не самое лучшее решение. С моей кочки зрения правильным будет сделать "быструю проверку, не требующую выхода в тыртырнет". Если результат "быстрой проверки" отрицательный (родительский/офисный контроль или "известные рассадники") - возвращаем "403 Ферботтен". Если положительный - возвращаем исходный ответ (возможно подкорректировав на формальную корректность) и начинаем остальные проверки тогда, когда UA сделает переход на Location.

 

Мы не проверяем Location, мы ждем, когда все заголовки передадут, а нам вместо этого -- обрыв соединения. Мы работаем "прозрачно", поэтому статус Bad gateway нам не совсем подходит.

[basid]

Мы не проверяем Location, мы ждем, когда все заголовки передадут, а нам вместо этого -- обрыв соединения. Мы работаем "прозрачно", поэтому статус Bad gateway нам не совсем подходит.

"Вы, батюшка, определитесь ...".
Если прозрачно, то передаются все строки заголовка, которые передал сервер и все байты тела сообщения: A client, server, or proxy MAY close the transport connection at any time

[Alexander Chinyakov]

Мы не проверяем Location, мы ждем, когда все заголовки передадут, а нам вместо этого -- обрыв соединения. Мы работаем "прозрачно", поэтому статус Bad gateway нам не совсем подходит.

 

"Вы, батюшка, определитесь ...".
Если прозрачно, то передаются все строки заголовка, которые передал сервер и все байты тела сообщения: A client, server, or proxy MAY close the transport connection at any time

 

Определяюсь: термин «прозрачно» применительно к работе НетФильтра означает, что мы представляемся сервером клиенту и наоборот, а не каким-либо промежуточным звеном — прокси-сервером, шлюзом, и т.п. В частности, это подразумевает полную замену ответа в случае обнаружения в нем угрозы: код 503 и заголовки, соответствующие содержимому (странице блокировки).

 

Также, я еще раз подчеркиваю, что в данном случае имеет место неопределенное поведение из-за нарушения протокола. Возможно, это повод применять для рассматриваемого случая настройку «Блокировать поврежденные объекты».

[basid]

Определяюсь: термин «прозрачно» применительно к работе НетФильтра означает, что

... вы полностью должны соблюдать правило "педантичности и толерантности".

Также, я еще раз подчеркиваю, что в данном случае имеет место неопределенное поведение из-за нарушения протокола. Возможно, это повод применять для рассматриваемого случая настройку «Блокировать поврежденные объекты».

Это плохое решение. Можно обсуждать необходимость добавления завершающей пустой строки, но не более того.

[v.martyanov]

Я тоже считаю что мы не должны ничего блокировать, если там нет угрозы. malformed http headers угрозы не представляют и должны отдаваться "наверх" как есть, пока не будет PoC с эксплуатацией.

[Alexander Chinyakov]

Я тоже считаю что мы не должны ничего блокировать, если там нет угрозы. malformed http headers угрозы не представляют и должны отдаваться "наверх" как есть, пока не будет PoC с эксплуатацией.

 

Вот потому и прикручу к настройке "блокировать поврежденные объекты" -- оно как раз для вот таких случаев и по умолчанию выключено.