(немного оффтоп здесь)
Это называется предварительной загрузкой HSTS, см. https://hstspreload.org/
HSTS (HTTP Strict Transport Security) - это способ, которым серверы могут отвечать клиентам: пожалуйста, свяжитесь со мной только через HTTPS (см. https://www.troyhunt.com/the-6-step-happy-path-to-https/ для примеров). Это повышает безопасность, но все еще не решает один случай: первое соединение с данным сервером может произойти по HTTP, прежде чем браузер узнает, что он должен вместо этого выполнить HTTPS.
Отсюда и «предварительная загрузка» HSTS.
По сути, это жестко закодированный список, включенный во все основные коды браузеров.
(см. https://caniuse.com/#feat=stricttransportsecurity, чтобы узнать о совместимости в зависимости от браузера и версии, или см. внизу ссылки на код [1]), в котором указано, какие домены / TLD поддерживают HSTS, что означает, что к ним вообще не разрешено HTTP-соединение.
Обратите внимание, что:
- Любой может отправлять имена в этот список, следуя некоторым требованиям, см. https://hstspreload.org/#submission-requirements
- Google (так как он начинался с Chrome, но теперь распространен среди браузеров) приветствует включение TLD, а не только имен хостов, см. Конец документа в https://hstspreload.org/ («Предварительная загрузка TLD»)
Они уже добавили .DEV
в прошлом (домен TLD сам по себе еще не запущен, но Google запустит его "в ближайшее время"), что нарушило настрой многих разработчиков, когда они (неправильно) использовали доменное имя .DEV
для называть свои локальные ресурсы, и как только их браузеры были обновлены с помощью нового списка предварительной загрузки HSTS, они отказались подключаться к своему локальному .DEV
узлу без HTTPS. Вы можете найти здесь и в других местах (например: https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/) множество ужасных историй разработчиков, которые выступают против этого, а также, возможно, люди, предлагающие плохие решения для этого (например, отключение предварительной загрузки HSTS, что является очень плохой идеей).
Также, когда вы покупаете доменное имя .APP
(и оно будет таким же для .DEV
), Google (как реестр .APP
) по контракту удостоверился со всеми регистраторами, что они будут, во время проверки .APP
покупка доменного имени, отображение заметного сообщения, в котором говорится что-то вроде: «.APP - безопасный ДВУ, и веб-сайты будут работать только с SSL-сертификатом (sic); убедитесь, что вы покупаете SSL-сертификат» (SSL-сертификат прямо документации Google, и это очень печально читать из них, так как это вдвойне неправильный термин, это должен был быть «сертификат X.509» или, чтобы никого не пугать, хотя бы «сертификат, используемый для связи TLS» ", в наше время никто не должен использовать SSL ...).
Кстати, .APP
открылся для публики по стандартным ценам вчера, 8 мая.
Конечно, все это относится только к просмотру веб-страниц. Вы можете установить любой другой вид сервиса, например, электронную почту, поверх .APP
доменного имени, без обязательного протокола TLS (что, конечно, не очень хорошая идея в наше время, но ничто не удержит вас от этого). Что касается электронной почты, в настоящее время ведутся дискуссии о том, чтобы иметь в основном HSTS, но для MTA, см. https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/
[1] см. Некоторые исходники со списком предварительной загрузки HSTS:
или вы можете использовать API на https://hstspreload.com/, чтобы узнать, есть ли имя в списке