Как Google заставляет HTTPS использовать их домен .app? - PullRequest
0 голосов
/ 09 мая 2018

В I / O 2018 Google объявил о своем новом TLD .app, и они сказали, что это будет только HTTPS.

Я думал, что DNS просто сопоставляет доменные имена с IP-адресами.

Как они заставляют HTTPS?

Ответы [ 2 ]

0 голосов
/ 09 мая 2018

(немного оффтоп здесь)

Это называется предварительной загрузкой 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-соединение.

Обратите внимание, что:

  1. Любой может отправлять имена в этот список, следуя некоторым требованиям, см. https://hstspreload.org/#submission-requirements
  2. 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/, чтобы узнать, есть ли имя в списке

0 голосов
/ 09 мая 2018

Это просто политика. Доменное имя - это доменное имя, а DNS заботится только о том, как имя переводится на другие ресурсы, например, на IP-адрес. Технически любой IP-адрес может использоваться вместе с любым IP-протоколом (можно выбрать из 256, один из которых - TCP) и, когда это применимо, любой номер порта (доступно 65536, два из которых HTTP и HTTPS соответственно) , Невозможно наложить ограничения на это через DNS, но, конечно, регистратор TLD может попытаться сделать это с помощью правил политики.

Методом проб и ошибок я легко нашел домен .app, где HTTPS не применяется:

curl -v -L http://foo.app/

Это приводит к нескольким перенаправлениям, но ни одно из них не перенаправляет на HTTPS, а окончательный ответ - это HTTP-ответ от адреса GoDaddy.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...