Обновления
23 марта 2023 г .: график обновлен, поддержка прекращается только в Chrome 117.
19 января 2023 г .: график обновлен, поддержка прекращается только в Chrome 114.
12 августа 2022 г .: график обновлен, поддержка прекращается только в Chrome 109.
10 февраля 2022 г .: На сайте Private Network Access опубликована обновленная статья: введение в предварительную проверку.
25 августа 2021 г .: Обновлено объявление о графике и введена пробная версия прекращения поддержки.
Chrome прекращает поддержку доступа к конечным точкам частной сети с незащищенных веб-сайтов в рамках спецификации доступа к частной сети . Цель состоит в том, чтобы защитить пользователей от атак с подделкой межсайтовых запросов (CSRF), нацеленных на маршрутизаторы и другие устройства в частных сетях. Эти атаки затронули сотни тысяч пользователей , что позволило злоумышленникам перенаправить их на вредоносные серверы.
Chrome внесет следующие изменения:
- Блокировка запросов к частным сетям от небезопасных общедоступных веб-сайтов, начиная с Chrome 94.
- Представляем пробную версию , которая завершится в Chrome
- Это позволит разработчикам запрашивать продление времени для выбранных источников, на которое не повлияет пробная версия устаревания.
- Представляем политику Chrome, которая позволит управляемым развертываниям Chrome навсегда обойти прекращение поддержки. Доступно в Chrome 92.
Если вам нужно больше времени, чтобы смягчить влияние отказа от поддержки, зарегистрируйте его для пробной версии.
Если у вас есть административный контроль над вашими пользователями, вы можете повторно включить эту функцию с помощью политик Chrome.
Чтобы смягчить влияние новых ограничений, используйте одну из следующих стратегий:
- Обновите свой веб-сайт до HTTPS и, при необходимости, целевой сервер .
- Обновите свой веб-сайт до HTTPS и используйте WebTransport .
- Обратное отношение внедрения .
Хронология
- Ноябрь 2020 г.: попросите оставить отзыв о предстоящих изменениях.
- Март 2021 г.: после рассмотрения отзывов и проведения разъяснительной работы объявляются предстоящие изменения. Спецификация переименована с CORS-RFC1918 в Private Network Access.
- Апрель 2021 г.: Chrome 90 выходит в стабильную версию, появляются предупреждения об устаревании.
- Июнь 2021 г.: Chrome 92 выходит в бета-версию, запрещая запросы к частным сетям из небезопасных контекстов. После отзывов разработчиков, просящих больше времени для адаптации, прекращение поддержки переносится на Chrome 93 и сопровождается пробной версией устаревания.
- Июль 2021 г.: после дальнейших отзывов разработчиков прекращение поддержки и сопутствующая пробная версия перенесены на Chrome 94. Кроме того, прекращение поддержки больше не затрагивает частные веб-сайты.
- Август 2021 г.: Chrome 94 выходит в бета-версию. Веб-разработчики могут начать подписаться на пробную версию устаревшей версии.
- Сентябрь 2021 г.: Chrome 94 выходит в стабильную версию. Веб-разработчикам следовало подписаться на пробную версию устаревшей версии и развернуть пробные токены в рабочей среде.
- Декабрь 2022 г.: отправлен опрос о пробной версии Origin и получены отзывы. Пробная версия устаревшей версии распространяется на Chrome 113.
- Март 2023 г.: пробная версия устаревшей версии распространяется на Chrome 116 и заканчивается в Chrome 117. Альтернативный механизм на основе разрешений находится в разработке и ориентирован на первоначальный выпуск Chrome 114.
- Май 2023 г. (ориентировочно): механизм на основе разрешений будет реализован в Chrome 114. Веб-сайты смогут использовать его для выхода из пробного периода устаревания.
- Сентябрь 2023 г.: Chrome 117 выходит в стабильную версию, что завершает пробную версию устаревшей версии. Chrome блокирует все запросы частной сети из общедоступных незащищенных контекстов.
Что такое доступ к частной сети
Доступ к частной сети (ранее известный как CORS-RFC1918) ограничивает возможность веб-сайтов отправлять запросы на серверы в частных сетях. Он разрешает такие запросы только из безопасного контекста. Спецификация также расширяет протокол совместного использования ресурсов между источниками (CORS), так что веб-сайты теперь должны явно запрашивать разрешение у серверов в частных сетях, прежде чем им будет разрешено отправлять произвольные запросы.
Запросы частной сети — это запросы, IP-адрес целевого сервера которых более приватен, чем тот, с которого был получен инициатор запроса. Например, запрос с общедоступного веб-сайта ( https://example.com ) на частный веб-сайт ( http://router.local ) или запрос с частного веб-сайта на localhost.
Дополнительные сведения см. в разделе Требуется обратная связь: CORS для частных сетей (RFC1918) .
Что такое пробная версия устаревания
Испытания устаревания (ранее известные как испытания обратного происхождения) — это форма испытаний происхождения, используемая для облегчения прекращения поддержки веб-функций. Пробные версии устаревания позволяют Chrome объявить устаревшими определенные веб-функции и предотвратить формирование новых зависимостей веб-сайтов от них, в то же время давая текущим зависимым веб-сайтам дополнительное время для перехода от них.
Во время пробной версии устаревшие функции по умолчанию недоступны для всех веб-сайтов. Разработчики, которым все еще необходимо использовать затронутые функции, должны подписаться на пробную версию устаревания и получить токены для определенных веб-источников, а затем изменить свои веб-сайты для обслуживания этих токенов в заголовках HTTP или метатегах (за исключением этого случая). Если веб-сайт предоставляет действительные токены, соответствующие их происхождению, Chrome разрешит использование устаревшей функции в течение ограниченного периода времени.
Для получения дополнительной информации ознакомьтесь с инструкциями в разделе «Начало работы с пробными версиями исходного кода Chrome» и в руководстве для веб-разработчиков по исходным пробным версиям .
Что изменится в Chrome
Хром 94
Начиная с Chrome 94, общедоступным незащищенным контекстам (в широком смысле, веб-сайтам, которые не доставляются по HTTPS или с частного IP-адреса) запрещено отправлять запросы в частную сеть. Ранее это было запланировано для Chrome 92, поэтому в сообщениях об устаревании все еще может упоминаться более ранний этап.
Это прекращение поддержки сопровождается пробной версией устаревания, позволяющей веб-разработчикам, чьи веб-сайты используют устаревшую функцию, продолжать использовать ее до версии Chrome 116, зарегистрировавшись для получения токенов. Ниже приведены инструкции о том, как зарегистрироваться и включить пробную версию на своем веб-сайте.
Можно использовать пару политик Chrome для отключения устаревания либо полностью, либо для определенных источников на неопределенный срок. Это позволяет избежать сбоев управляемых установок Chrome, например, в корпоративных настройках.
Хром 117
Испытание устаревания завершено. Все веб-сайты должны быть перенесены с устаревшей функции или настроены политики их пользователей для продолжения включения этой функции.
Рекомендуемые действия разработчика
Первым шагом для затронутых веб-сайтов, скорее всего, будет выиграть некоторое время, пока не будет развернуто правильное исправление: либо путем регистрации для участия в пробной версии , либо с помощью политик. Далее рекомендуемый порядок действий варьируется в зависимости от обстоятельств каждого затронутого веб-сайта.
Зарегистрируйтесь для участия в пробной версии устаревания
- Нажмите «Зарегистрироваться для доступа к частной сети из пробного источника незащищенных контекстов», чтобы получить пробный токен для участвующего источника.
- Добавьте
Origin-Trial: $tokenдля конкретного источника в заголовок ответа . Этот заголовок ответа необходимо устанавливать только в ответах на основной ресурс и навигацию, если в результирующем документе используется устаревшая функция. Бесполезно (хотя и безвредно) прикреплять этот заголовок к ответам подресурса.
Поскольку эту пробную версию необходимо включить или отключить, прежде чем документу будет разрешено делать какие-либо запросы, ее нельзя включить с помощью тега <meta> . Такие теги анализируются из тела ответа только после того, как могут быть отправлены запросы подресурсов. Это представляет проблему для веб-сайтов, не контролирующих заголовки ответов, таких как статические веб-сайты github.io, обслуживаемые третьей стороной.
Дополнительные сведения см. в руководстве веб-разработчика по пробным версиям Origin .
Включить политики
Если у вас есть административный контроль над вашими пользователями, вы можете повторно включить устаревшую функцию, используя одну из следующих политик:
Дополнительные сведения об управлении политиками для ваших пользователей см. в этой статье Справочного центра .
Доступ к локальному хосту
Если вашему веб-сайту необходимо отправлять запросы на локальный хост, вам просто нужно обновить его до HTTPS .
Запросы, нацеленные на http://localhost (или http://127.*.*.* , http://[::1] ), не блокируются смешанным содержимым, даже если они отправляются из безопасного контекста.
Обратите внимание, что движок WebKit и браузеры на его основе (в первую очередь Safari) отклоняются здесь от спецификации W3C Mixed Content и запрещают эти запросы как Mixed Content . Они также не реализуют доступ к частной сети, поэтому веб-сайты могут захотеть перенаправить клиентов, использующих такие браузеры, на HTTP-версию веб-сайта в виде открытого текста, которой такие браузеры по-прежнему разрешат отправлять запросы на локальный хост.
Доступ к частным IP-адресам
Если вашему веб-сайту необходимо отправлять запросы на целевой сервер по частному IP-адресу, то простое обновление веб-сайта-инициатора до HTTPS не сработает. Смешанный контент не позволяет безопасным контекстам отправлять запросы через HTTP в виде обычного текста, поэтому недавно защищенный веб-сайт по-прежнему не сможет выполнять запросы. Есть несколько способов решить эту проблему:
- Обновите оба конца до HTTPS.
- Используйте WebTransport для безопасного подключения к целевому серверу.
- Обратное отношение встраивания.
Обновите оба конца до HTTPS
Это решение требует контроля над разрешением DNS пользователей, например, в контексте интрасети или если пользователи получают адреса своих серверов имен от DHCP-сервера, находящегося под вашим контролем. Это также требует, чтобы у вас было общедоступное доменное имя.
Основная проблема с обслуживанием частных веб-сайтов через HTTPS заключается в том, что центры сертификации инфраструктуры открытых ключей (PKI CA) предоставляют сертификаты TLS только веб-сайтам с общедоступными доменными именами. Чтобы обойти это:
- Зарегистрируйте общедоступное доменное имя (например,
intranet.example) и опубликуйте записи DNS, указывающие это доменное имя на общедоступный сервер по вашему выбору. - Получите сертификат TLS для
intranet.example. - Внутри вашей частной сети настройте DNS для разрешения
intranet.exampleв частный IP-адрес целевого сервера. - Настройте свой частный сервер на использование сертификата TLS для
intranet.example. Это позволит вашим пользователям получить доступ к частному серверу по адресуhttps://intranet.example.
Затем вы можете обновить веб-сайт, который инициирует запросы, до HTTPS и продолжать отправлять запросы, как и раньше.
Это решение ориентировано на будущее и снижает доверие, которое вы оказываете своей сети, расширяя использование сквозного шифрования в вашей частной сети.
ВебТранспорт
Это решение не требует контроля над разрешением DNS ваших пользователей. Для этого требуется, чтобы на целевом сервере работал минимальный сервер WebTransport (сервер HTTP/3 с некоторыми изменениями).
Вы можете обойти отсутствие действующего сертификата TLS, подписанного доверенным центром сертификации, с помощью WebTransport и его механизма закрепления сертификата . Это позволяет, например, устанавливать безопасные соединения с частными устройствами, которые могут иметь самозаверяющий сертификат. Соединения WebTransport допускают двунаправленную передачу данных, но не позволяют получать запросы. Вы можете комбинировать этот подход с сервисным работником для прозрачного проксирования HTTP-запросов через соединение с точки зрения вашего веб-приложения. На стороне сервера соответствующий уровень трансляции может преобразовывать сообщения WebTransport в HTTP-запросы.
Мы признаем, что это требует немалого объема работы, но это должно быть значительно проще, чем создание на базе WebRTC; мы также надеемся, что некоторая часть необходимых инвестиций будет реализована в виде библиотек многократного использования. Мы также считаем, что это особенно важно, учитывая тот факт, что незащищенные контексты, скорее всего, потеряют доступ ко все большему количеству функций веб-платформы, поскольку платформа со временем движется к более активному использованию HTTPS. Независимо от доступа к частной сети, в любом случае это, вероятно, будет разумной инвестицией.
Мы ожидаем, что WebTransport over HTTP/3 будет поставляться в Chrome 96 (он уже начал пробную версию ) со средствами защиты от совместного использования ключей и других некачественных мер безопасности, в том числе:
- Короткий максимальный срок действия закрепленных сертификатов.
- Специальный для браузера механизм отзыва определенных ключей, которые подверглись злоупотреблениям.
Мы не будем реализовывать ограничение безопасного контекста, пока не пройдут как минимум два этапа после полного развертывания WebTransport. При необходимости срок прекращения поддержки будет продлен.
Обратное встраивание
Это решение не требует какого-либо административного контроля над сетью и может использоваться, когда целевой сервер недостаточно мощный для запуска HTTPS.
Вместо получения частных подресурсов из общедоступного веб-приложения скелет приложения может обслуживаться с частного сервера, который затем извлекает все свои подресурсы (например, сценарии или изображения) с общедоступного сервера, такого как CDN. Полученное веб-приложение может затем отправлять запросы на частный сервер, поскольку они считаются имеющими одно и то же происхождение. Он даже может отправлять запросы к другим серверам с частными IP-адресами (но не с локальным хостом), хотя в долгосрочной перспективе это может измениться.
Размещая на частном сервере только скелет, вы можете обновлять веб-приложение, передавая новые ресурсы на общедоступный сервер, так же, как вы обновляете общедоступное веб-приложение. С другой стороны, полученное веб-приложение не является безопасным контекстом, поэтому у него нет доступа к некоторым наиболее мощным функциям Интернета.
Планы на будущее
Ограничение запросов к частной сети безопасными контекстами — это только первый шаг к запуску доступа к частной сети. Chrome работает над реализацией остальной части спецификации в ближайшие месяцы. Следите за обновлениями!
Ограничение доступа к локальному хосту с частных веб-сайтов
Изменения в Chrome 94 касаются только общедоступных веб-сайтов, имеющих доступ к частным IP-адресам или локальному хосту. Спецификация доступа к частной сети также классифицирует запросы с частных веб-сайтов на локальный хост как проблемные. Chrome со временем тоже откажется от их поддержки. Однако это создает несколько иной набор проблем, поскольку многие частные веб-сайты не имеют доменных имен, что усложняет использование устаревших пробных токенов.
Предполетные запросы CORS
Вторая часть доступа к частной сети заключается в шлюзовании запросов частной сети, инициированных из безопасных контекстов, с помощью предполетных запросов CORS . Идея состоит в том, что даже если запрос был инициирован из безопасного контекста, целевому серверу предлагается предоставить явное разрешение инициатору. Запрос отправляется только в случае успешного предоставления гранта.
Короче говоря, предварительный запрос CORS — это запрос HTTP OPTIONS содержащий некоторые заголовки Access-Control-Request-* указывающие характер последующего запроса. Затем сервер может решить, предоставлять или нет детальный доступ, ответив 200 OK заголовками Access-Control-Allow-* .
Подробнее об этом читайте в спецификации .
Ограничить выборку навигации
Chrome устаревает и в конечном итоге блокирует запросы подресурсов к частным сетям. Это не повлияет на переходы к частным сетям, которые также могут использоваться в атаках CSRF .
Спецификация доступа к частной сети не делает различия между двумя видами выборки, на которые в конечном итоге будут распространяться одни и те же ограничения.
Фото на обложке: Маркус Списке на Unsplash