Suicide
24.08.2020, 19:40
Регистратор APNIC, отвечающий за распределение IP-адресов в Азиатско-Тихоокеанском регионе, опубликовал (https://blog.apnic.net/2020/08/21/chromiums-impact-on-root-dns-traffic/) результаты анализа распределения трафика на одном из корневых DNS-серверов a.root-servers.net. 45.80% запросов к корневому серверу оказались связаны с проверками, выполняемыми браузерами на основе движка Chromium. Таким образом, почти половина ресурсов корневых DNS-серверов уходит на выполнение диагностических проверок Chromium, а не обработку запросов от DNS-серверов при определении корневых зон. С учётом того, что Chrome занимает 70% рынка web-браузеров, подобная диагностическая активность приводит к отправке около 60 миллиардов запросов к корневым серверам в день.
Диагностические проверки используются в Chromium для определения применения провайдерами сервисов, перенаправляющих запросы к несуществующим именам на свои обработчики. Подобные системы внедряются некоторыми провайдерами для направления на себя трафика к доменным именам, введённым с ошибкой - как правило, для несуществующих доменов показываются страницы с предупреждением об ошибке, предложением списка вероятно правильных имён и рекламой. При этом подобная активность полностью разрушает логику определения интранет-хостов в браузере.
При обработке поискового запроса, введённого в адресной строке, если введено только одно слово без точек, браузер вначале пытается (https://www.opennet.ru/opennews/art.shtml?num=53178) определить данное слово в DNS, полагая, что пользователь может пытаться обратиться к интранет-сайту во внутренней сети, а не отправляет запрос поисковой системе. В случае если провайдер перенаправляет на себя запросы к несуществующим доменным именам, у пользователей возникает проблема - любые поисковые запросы из одного слова, введённые в адресной строке, начинают перенаправляться на страницы провайдера, а не направляться в поисковую систему.
Для решения возникшей проблемы разработчики Chromium добавили в браузер дополнительные проверки (https://chromium.googlesource.com/chromium/src/+/master/chrome/browser/intranet_redirect_detector.cc#147), которые в случае выявления перенаправлений изменяют логику обработки запросов в адресной строке. При каждом запуске, изменении настроек DNS или смене IP-адреса браузер отправляет три DNS-запроса со случайными именами доменов первого уровня, которые с высокой вероятностью не существуют. Имена включают от 7 до 15 латинских букв (без точек) и используются для выявления перенаправления несуществующих доменных имён провайдером на свой хост. Если при обработке трёх HTTP-запросов со случайными именами для двух будет получен редирект на одну и ту же страницу, то Chromium считает, что пользователь переброшен на стороннюю страницу.
В качестве признаков для выделения активности Chromium из общего потока запросов на корневом DNS-сервере были использованы нетипичные размеры домена первого уровня (от 7 до 15 букв) и фактор повторяемости запросов (имена каждый раз генерировались случайно и не повторялись). В логе были вначале отфильтрованы запросы несуществующих доменов (78.09%), потом выделены запросы, повторяющиеся не более трёх раз (51.41%), а затем отфильтрованы домены, включающие от 7 до 15 букв (45.80%). Интересно, что только 21.91% запросов к корневым серверам оказались связаны с определением существующих доменов.
https://www.opennet.ru/opennews/pics_base/0_1598255037.png (https://blog.apnic.net/wp-content/uploads/2020/08/Fig2_Chromium_sankey-graph-1320x493.png)
В ходе исследования также была изучена зависимость роста нагрузки на корневые серверы a.root-servers.net и j.root-servers.net от роста популярности Chrome.
https://www.opennet.ru/opennews/pics_base/0_1598255477.png (https://blog.apnic.net/wp-content/uploads/2020/08/Fig3_Chromium_long-term-analysis-graph.png)
В Firefox проверки перенаправления через DNS ограничиваются (https://wiki.mozilla.org/QA/Captive_Portals) определением переадресации на страницы аутентификации (captive portal) и реализованы (https://support.mozilla.org/en-US/questions/1251590) с использованием (https://dxr.mozilla.org/mozilla-central/source/toolkit/components/captivedetect) фиксированного поддомена "detectportal.firefox.com", без запроса доменных имён первого уровня. Подобное поведение не создаёт дополнительной нагрузки на корневые DNS-серверы, но потенциально может рассматриваться (https://bugzilla.mozilla.org/show_bug.cgi?id=1307867) как утечка конфиденциальных данных об IP-адресе пользователя (при каждом запуске запрашивается страница "detectportal.firefox.com/success.txt"). Для отключения проверки в Firefox предусмотрена настройка "network.captive-portal-service.enabled", которую можно изменить на странице "about:config".
24.08.2020
https://www.opennet.ru/opennews/art.shtml?num=53587
Диагностические проверки используются в Chromium для определения применения провайдерами сервисов, перенаправляющих запросы к несуществующим именам на свои обработчики. Подобные системы внедряются некоторыми провайдерами для направления на себя трафика к доменным именам, введённым с ошибкой - как правило, для несуществующих доменов показываются страницы с предупреждением об ошибке, предложением списка вероятно правильных имён и рекламой. При этом подобная активность полностью разрушает логику определения интранет-хостов в браузере.
При обработке поискового запроса, введённого в адресной строке, если введено только одно слово без точек, браузер вначале пытается (https://www.opennet.ru/opennews/art.shtml?num=53178) определить данное слово в DNS, полагая, что пользователь может пытаться обратиться к интранет-сайту во внутренней сети, а не отправляет запрос поисковой системе. В случае если провайдер перенаправляет на себя запросы к несуществующим доменным именам, у пользователей возникает проблема - любые поисковые запросы из одного слова, введённые в адресной строке, начинают перенаправляться на страницы провайдера, а не направляться в поисковую систему.
Для решения возникшей проблемы разработчики Chromium добавили в браузер дополнительные проверки (https://chromium.googlesource.com/chromium/src/+/master/chrome/browser/intranet_redirect_detector.cc#147), которые в случае выявления перенаправлений изменяют логику обработки запросов в адресной строке. При каждом запуске, изменении настроек DNS или смене IP-адреса браузер отправляет три DNS-запроса со случайными именами доменов первого уровня, которые с высокой вероятностью не существуют. Имена включают от 7 до 15 латинских букв (без точек) и используются для выявления перенаправления несуществующих доменных имён провайдером на свой хост. Если при обработке трёх HTTP-запросов со случайными именами для двух будет получен редирект на одну и ту же страницу, то Chromium считает, что пользователь переброшен на стороннюю страницу.
В качестве признаков для выделения активности Chromium из общего потока запросов на корневом DNS-сервере были использованы нетипичные размеры домена первого уровня (от 7 до 15 букв) и фактор повторяемости запросов (имена каждый раз генерировались случайно и не повторялись). В логе были вначале отфильтрованы запросы несуществующих доменов (78.09%), потом выделены запросы, повторяющиеся не более трёх раз (51.41%), а затем отфильтрованы домены, включающие от 7 до 15 букв (45.80%). Интересно, что только 21.91% запросов к корневым серверам оказались связаны с определением существующих доменов.
https://www.opennet.ru/opennews/pics_base/0_1598255037.png (https://blog.apnic.net/wp-content/uploads/2020/08/Fig2_Chromium_sankey-graph-1320x493.png)
В ходе исследования также была изучена зависимость роста нагрузки на корневые серверы a.root-servers.net и j.root-servers.net от роста популярности Chrome.
https://www.opennet.ru/opennews/pics_base/0_1598255477.png (https://blog.apnic.net/wp-content/uploads/2020/08/Fig3_Chromium_long-term-analysis-graph.png)
В Firefox проверки перенаправления через DNS ограничиваются (https://wiki.mozilla.org/QA/Captive_Portals) определением переадресации на страницы аутентификации (captive portal) и реализованы (https://support.mozilla.org/en-US/questions/1251590) с использованием (https://dxr.mozilla.org/mozilla-central/source/toolkit/components/captivedetect) фиксированного поддомена "detectportal.firefox.com", без запроса доменных имён первого уровня. Подобное поведение не создаёт дополнительной нагрузки на корневые DNS-серверы, но потенциально может рассматриваться (https://bugzilla.mozilla.org/show_bug.cgi?id=1307867) как утечка конфиденциальных данных об IP-адресе пользователя (при каждом запуске запрашивается страница "detectportal.firefox.com/success.txt"). Для отключения проверки в Firefox предусмотрена настройка "network.captive-portal-service.enabled", которую можно изменить на странице "about:config".
24.08.2020
https://www.opennet.ru/opennews/art.shtml?num=53587