Иногда люди хотят получить сертификат для имени хоста «localhost», либо для использования в локальной разработке, либо для распространения с помощью родного приложения, которое должно взаимодействовать с веб-приложением. Предположим, что Let’s Encrypt не может предоставить сертификаты для «localhost», потому что никто не является его уникальным владельцем, и он не внедрен в домен высшего уровня, например «.com» или «.net». Но возможно настроить собственное доменное имя, которое, как выясняется, должно быть 127.0.0.1, и получить сертификат для него с помощью запроса DNS. Однако это, как правило, является плохой идеей, и существуют намного лучшие варианты.
Для локальной разработки
Если вы разрабатываете веб-приложение, полезно запустить локальный веб-сервер, например, Apache или Nginx, и получить доступ к нему через
Лучший вариант заключается в следующем: Создайте собственный сертификат, либо самостоятельно подписанный, либо подписанный локальным корневым пользователем, и добавьте его в доверенное хранилище (trust store) вашей операционной системы. Затем используйте этот сертификат на своем локальном веб-сервере. Более подробное описание указано ниже.
Коммуникация для родных приложений с веб-приложениями
Иногда разработчики хотят предложить загружаемое родное приложение, которое может быть использовано совместно с веб-сайтом, чтобы предлагать дополнительные функции. Например, настольные приложения Dropbox и Spotify сканируют файлы со всей вашей машины, что, например, веб-приложение не сможет сделать. Один из распространенных подходов заключается в том, чтобы эти родные приложения предлагали веб-службу на локальном хосте, и обрабатывали запросы через XMLHTTPRequest (XHR) или WebSockets. Веб-приложение почти всегда использует HTTPS, что означает, что браузеры запретят ему делать запросы XHR или WebSockets незащищенным URL-адресам. Это называется блокировкой смешанного содержимого (Mixed Content Blocking). Для коммуникации с веб-приложением, родное приложение должно обеспечить безопасный веб-сервис.
К счастью для нас, современные браузеры
Возможно, у вас возникнет соблазн обойти эти ограничения, настроив доменное имя в глобальном DNS, которое, как выясняется, должно быть 127.0.0.1 (например, localhost.example.com), получив сертификат для этого имени домена, отправив этот сертификат и соответствующий секретный ключ с вашим родным приложением и сообщив вашему веб-приложению выстраивать коммуникацию с с
Представляя доменное имя вместо IP-адреса, вы позволяете злоумышленнику использовать атаку «человек посередине» (Man in Middle (MitM)) против DNS поиска и вводить ответ, который указывает на другой IP-адрес. Затем злоумышленник может притворяться локальным приложением и отправлять фальшивые ответы обратно в веб-приложение, что может поставить под угрозу вашу учетную запись на стороне веб-приложения в зависимости от того, каким образом она создана.
Успех проведения атаки «человек посередине» (MitM) в этой ситуации возможен, потому что для того, чтобы заставить её работать, вам пришлось отправить секретный ключ в свой сертификат с помощью родного приложения. Это означает, что любой, кто загружает ваше родное приложение, получает копию закрытого ключа, включая злоумышленника. Это считается компрометацией вашего закрытого ключа, и ваш центр сертификации (Certificate Authority (CA)) должен отозвать ваш сертификат, как только он узнает об этом.
К сожалению, это оставляет родные приложения без большого количества полезных, безопасных опций для коммуникации с соответствующим веб-сайтом. И ситуация может стать более сложной в будущем, если браузеры еще больше
Также обратите внимание, что экспорт веб-сервиса, который предлагает привилегированные родные API, по своей сути является довольно рискованным и ненадежным, потому что веб-сайты, авторизовать которые вы не собираетесь, могут получить к ним доступ. Если вы все же пошли этим путем, обязательно прочитайте раздел
Создание и доверие к вашим собственным сертификатам
Любой может сделать свои сертификаты без помощи центра сертификации (Certificate Authority (CA)). Единственное различие заключается в том, что сертификаты, которые вы делаете сами, не будут вызвать доверия у кого-либо еще. Для локальной разработки это является вполне нормальным.
Самым простым способом сгенерировать закрытый ключ и самозаверяющий сертификат для локального хоста является команда openssl:
Затем вы можете настроить локальный веб-сервер с помощью localhost.crt и localhost.key и установить localhost.crt в свой список локально доверенных корней.
Если вы хотите получить больше реализма в своих сертификатах разработки, вы можете использовать minica для создания собственного локального корневого сертификата и выдавать подписанные им сертификаты конечных объектов (также известные как leaf). Затем вы импортируете корневой сертификат, вместо самозаверяющего сертификата конечного объекта.
Вы также можете использовать домен с точками в нем, например «
Источник:
Для локальной разработки
Если вы разрабатываете веб-приложение, полезно запустить локальный веб-сервер, например, Apache или Nginx, и получить доступ к нему через
Ссылка скрыта от гостей
в вашем веб-браузере. Однако, веб-браузеры ведут себя по-разному на страницах HTTP и HTTPS. Основное различие: на странице HTTPS любые запросы на загрузку JavaScript из URL-адреса HTTP будут заблокированы. Поэтому, если вы разрабатываете локально с помощью HTTP, вы можете добавить тег скрипта, который отлично работает на вашей машине, на которой вы ведете разработки, но перестаёт работать при развертывании на вашем рабочем месте HTTPS. Чтобы разрешить эту проблему, полезно настроить HTTPS на локальном веб-сервере. Но вы не хотите видеть предупреждения сертификатов все время. Как вы получаете локальный зеленый код?Лучший вариант заключается в следующем: Создайте собственный сертификат, либо самостоятельно подписанный, либо подписанный локальным корневым пользователем, и добавьте его в доверенное хранилище (trust store) вашей операционной системы. Затем используйте этот сертификат на своем локальном веб-сервере. Более подробное описание указано ниже.
Коммуникация для родных приложений с веб-приложениями
Иногда разработчики хотят предложить загружаемое родное приложение, которое может быть использовано совместно с веб-сайтом, чтобы предлагать дополнительные функции. Например, настольные приложения Dropbox и Spotify сканируют файлы со всей вашей машины, что, например, веб-приложение не сможет сделать. Один из распространенных подходов заключается в том, чтобы эти родные приложения предлагали веб-службу на локальном хосте, и обрабатывали запросы через XMLHTTPRequest (XHR) или WebSockets. Веб-приложение почти всегда использует HTTPS, что означает, что браузеры запретят ему делать запросы XHR или WebSockets незащищенным URL-адресам. Это называется блокировкой смешанного содержимого (Mixed Content Blocking). Для коммуникации с веб-приложением, родное приложение должно обеспечить безопасный веб-сервис.
К счастью для нас, современные браузеры
Ссылка скрыта от гостей
как
Ссылка скрыта от гостей
URL, потому что она относится к кольцевому адресу (loopback address). Трафик, отправленный на 127.0.0.1, гарантированно не покидает вашу машину, и поэтому считается автоматически защищенным от перехвата сети. Это означает, что если ваше веб-приложение является HTTPS, и вы предлагаете родному приложению веб-сервис 127.0.0.1, эти два объекта могут без проблем обмениваться данными через XHR. К сожалению,
Ссылка скрыта от гостей
. WebSockets также не имеют такой возможности для любого имени.Возможно, у вас возникнет соблазн обойти эти ограничения, настроив доменное имя в глобальном DNS, которое, как выясняется, должно быть 127.0.0.1 (например, localhost.example.com), получив сертификат для этого имени домена, отправив этот сертификат и соответствующий секретный ключ с вашим родным приложением и сообщив вашему веб-приложению выстраивать коммуникацию с с
Ссылка скрыта от гостей
вместо
Ссылка скрыта от гостей
. Не делайте этого. Это поставит ваших пользователей под угрозу, и ваш сертификат может быть отозванПредставляя доменное имя вместо IP-адреса, вы позволяете злоумышленнику использовать атаку «человек посередине» (Man in Middle (MitM)) против DNS поиска и вводить ответ, который указывает на другой IP-адрес. Затем злоумышленник может притворяться локальным приложением и отправлять фальшивые ответы обратно в веб-приложение, что может поставить под угрозу вашу учетную запись на стороне веб-приложения в зависимости от того, каким образом она создана.
Успех проведения атаки «человек посередине» (MitM) в этой ситуации возможен, потому что для того, чтобы заставить её работать, вам пришлось отправить секретный ключ в свой сертификат с помощью родного приложения. Это означает, что любой, кто загружает ваше родное приложение, получает копию закрытого ключа, включая злоумышленника. Это считается компрометацией вашего закрытого ключа, и ваш центр сертификации (Certificate Authority (CA)) должен отозвать ваш сертификат, как только он узнает об этом.
Ссылка скрыта от гостей
Ссылка скрыта от гостей
из-за
Ссылка скрыта от гостей
.К сожалению, это оставляет родные приложения без большого количества полезных, безопасных опций для коммуникации с соответствующим веб-сайтом. И ситуация может стать более сложной в будущем, если браузеры еще больше
Ссылка скрыта от гостей
.Также обратите внимание, что экспорт веб-сервиса, который предлагает привилегированные родные API, по своей сути является довольно рискованным и ненадежным, потому что веб-сайты, авторизовать которые вы не собираетесь, могут получить к ним доступ. Если вы все же пошли этим путем, обязательно прочитайте раздел
Ссылка скрыта от гостей
(
Ссылка скрыта от гостей
), используйте Access-Control-Allow-Origin и убедитесь, что используете безопасный для памяти (memory-safe) HTTP-парсер, поскольку даже начальные адреса, которым вы не давали доступ могут отправлять предварительные запросы, которые могут использовать баги в вашем парсере.Создание и доверие к вашим собственным сертификатам
Любой может сделать свои сертификаты без помощи центра сертификации (Certificate Authority (CA)). Единственное различие заключается в том, что сертификаты, которые вы делаете сами, не будут вызвать доверия у кого-либо еще. Для локальной разработки это является вполне нормальным.
Самым простым способом сгенерировать закрытый ключ и самозаверяющий сертификат для локального хоста является команда openssl:
Код:
openssl req -x509 -out localhost.crt -keyout localhost.key \
-newkey rsa:2048 -nodes -sha256 \
-subj '/CN=localhost' -extensions EXT -config <( \
printf "[dn]\nCN=localhost\n[req]\ndistinguished_name = dn\n[EXT]\nsubjectAltName=DNS:localhost\nkeyUsage=digitalSignature\nextendedKeyUsage=serverAuth")Если вы хотите получить больше реализма в своих сертификатах разработки, вы можете использовать minica для создания собственного локального корневого сертификата и выдавать подписанные им сертификаты конечных объектов (также известные как leaf). Затем вы импортируете корневой сертификат, вместо самозаверяющего сертификата конечного объекта.
Вы также можете использовать домен с точками в нем, например «
Ссылка скрыта от гостей
, добавив его в /etc/hosts в качестве альтернативного имени для 127.0.0.1. Это незаметно изменит способ обработки файлов cookie браузерами.Источник:
Ссылка скрыта от гостей
Последнее редактирование модератором:
