Зачем Android-устройства отправляют GET-запросы на IP-адреса Google вида /generate_204?

Question

[Дмитрий Филимонов]

Фильтрация контента по реестру запрещенных сайтов в одном провайдере. Кроме URL и доменов были зарезаны также домены в виде IP-адресов. Но было замечено, что некоторые андройд-устройства обращаются к гуглу примерно так:

173.194.32.164/generate_204
173.194.32.163/generate_204
173.194.32.166/generate_204

Адресов больше, выше только малая часть. Попробовал обратиться, получил: HTTP/1.1 204 No Content.

Это штатная ситуация? Зачем обращаться именно с IP в качестве Host? Что будет, если зарезать данные обращения? Что именно делает такие запросы? И зачем?

P.S. stackoverflow.com/questions/1989214/google-com-and... - есть похожий вопрос, где есть множество предположений. Однако в тех случаях обращение происходит все же по доменным именам.

P.P.S. Сделал дамп у себя на домашнем роутере. Адрес 1.1.1.1 - роутер, 1.1.1.3 - телефон. Сначала он делает DNS запрос на определенный домен, далее обращается по IP. Такое происходит каждый раз после подключения по вай-фай. Позже зарезал любые пакеты, где встречается "generate_204" (iptables string), никаких изменений на телефоне не заметил. Пример дампа: https://dl.dropboxusercontent.com/u/53468586/toste...

Answer 1

[Андрей]

Это попытка гугла понять, если надо авторизовываться в сети или можно серфить прям так. Т.е., если вы зайдете в макдональдс, то гугл отправит этот запрос, получит ничего и скажет "надо авторизоваться".

Comments

[386DX]

собственно, первая ссылка с поисковика

Подсказки при ошибках навигации
Если вам не удалось найти нужную веб-страницу или установить подключение, сервер возвращает слишком короткое сообщение об ошибке (менее 512 байт) или вы попали на припаркованный домен, Google Chrome предложит подсказки, которые помогут найти то, что вы искали.

Сначала браузер сравнит адрес с локальным списком припаркованных доменов. При обнаружении совпадения он отправит хешированную частичную копию URL в Google, чтобы проверить правильность данных в списке. При этом используется тот же метод, что и для работы функции безопасного просмотра (он описан в разделе "Фишинг и вредоносное ПО" выше).

При возникновении других ошибок навигации Chrome отправит URL целевой веб-страницы в Google, предварительно удалив все GET-параметры, чтобы получить в ответ рекомендации. Эта информация регистрируется в журналах и очищается от личных данных так же, как и поисковые запросы Google. Журналы помогают нам реализовать эту функцию и улучшить ее работу.

Кроме того, если имя домена не найдено, Chrome анализирует причину сбоя, пытаясь определить заданное имя хоста (“google.com”) с помощью общего DNS-сервера Google и DNS-сервиса, установленного для вашей системы по умолчанию. Это позволяет пользователю получить больше информации об ошибке.

Если время ожидания подключения по протоколу SSL истечет, возникнут ошибки с сертификатом или другие проблемы с сетью, связанные с работой адаптивного портала (например, сети Wi-Fi в отеле), то Chrome отправит по адресу www.gstatic.com/generate_204 специальный запрос без файлов cookie, чтобы проверить отклик. Если запрос будет переадресован на другую страницу, она будет открыта в новой вкладке (скорее всего, это будет страница входа). Запросы на страницу проверки адаптивного портала не регистрируются.

Функцию подсказок при ошибках навигации можно отключить, сняв соответствующий флажок в разделе "Личные данные" в настройках Google Chrome.

[Дмитрий Филимонов]

Спасибо. Немного погуглив в эту сторону, нашел упоминания об этом в файле WifiWatchdogStateMachine.java в исходниках, но не во всех версиях. Видимо, позже этот алгоритм был впилен в другие места, но не суть важно. Это называется как-то вроде "walled garden check".

https://android.googlesource.com/platform/framewor...

"On DNS success, the WatchdogService initiates a walled garden check via an http get. A browser window is activated if a walled garden is detected."

Судя по той теме на stackoverflow, этот запрос много где используется. И однажды можно словить переход на страницу, что "данный ресурс заблокирован" (в случае с блокировкой от провайдера).

Что, собственно, я только что протестил. В уведомлениях появляется пункт, что требуется авторизация, после захода в браузер. Нажатие на него перекидывает туда, куда ведет редирект с этого адреса.

В принципе сделано логично все это, но блокировать IP гугла нельзя.

Всем огромное спасибо. Такая проверка, получается, где угодно может быть использована, в любом приложении.

[Дмитрий Филимонов]

@386DX Я имею в виду другое. Блокировку не на уровне L3, а на уровне L7 по заголовку в пакете http (Host). Это делает squid tproxy для ip-адресов из списка запрещенных сайтов, которые через эту проксю проходят после анонса по bgp.

Если так не делать, то блокировка легко обходится для многих сайтов, если так делать для всех, то есть проблемы вроде этой с гуглом.

Сейчас сделаю исключения насчет этого. Кстати говоря, собираюсь статью на хабр написать касательно реестра вообще, но не уверен, что ее хорошо примут. Для меня это все ради интереса, а не репрессивного сапога ради. Вообще обо всем: и о реестре, и о том, как это сделано, и о скриптах, которые все это делают (а там уже не просто портянка, а нечто похожее на нормальное ПО).

[Дмитрий Филимонов]

Хм.. ответил на комментарий, а его уже нет %)

[386DX]

@DmitryPhilimonov Deep packet inspection просто дороже вот ответ. Написано про это уже много

[Дмитрий Филимонов]

@386DX Кстати говоря, в свое время (чуть более года назад) не встретил ни одной вменяемой статьи насчет того, как это реализовано. Из хорошего есть только про выгрузку из реестра от netangels вроде. Но о примерах внутри провайдеров, полноценного опенсорса для работы с реестром, тонкости/фейлы в реестре (коих там много), как можно законно и правильно его обойти, а также почему не катят линуксовые возможности для организации именно DPI (а не прокси) ничего или почти ничего. На других ресурсах есть частные примеры, отрывки инфы, на хабре в основном политический уклон. Сейчас ситуация на хабре не изменилась. У меня уже есть в черновиках статья, плюс наработки, никак не могу закончить..)

Ну да ладно, вопрос был не об этом, так что не стоит тут флудить.

Answer 2

[386DX]

www.gstatic.com/generate_204
www.gstatic.com

Comments

[Дмитрий Филимонов]

Эмм... Что должен был пояснить ваш комментарий?

[386DX]

@DmitryPhilimonov предполагаю, что какая-то статичная информация с гугла отправляется\запрашивается с данного сервиса

www.gstatic.com/s2/sitemaps/sitemap-00001-of-50000.gz

[Дмитрий Филимонов]

@386DX Обновил пост, добавив туда домашний дамп.

[Сергей Протько]

@386DX это не может быть сбор данных о сетях/определение местоположения пользователя?

[386DX]

@Fesor Я давно заблочил гуглосервисы httpswitchboard и что они шлют не знаю

[386DX]

@Fesor по данным httpswitchboard запросы на gstatic.com идут чуть ли не с каждой страницы в инете. Собственно гугл шпионит, вроде ни для кого не новость