#security #websocket #executable #communication #npapi
#Безопасность #websocket #исполняемый файл #Информационные материалы #npapi
Вопрос:
Мне нужна информация о рисках безопасности и подтверждение концепций для работы с локальным клиентом.
В моем варианте пользователь установит два компонента:
- Игровой клиент
- Средство запуска клиента
Программа запуска все время работает как фоновый процесс. Программа запуска предоставляет WebSocket сервер. Пользователь откроет мой веб-сайт, чтобы начать игру (со списками игровых серверов и другими настройками). Веб-сайт подключается к программе запуска игр для выполнения всех действий (изменение конфигурации, запуск исполняемого файла игры)..
Проблема:
Как реализовать связь с веб-сайтом и программой запуска игр? Хорошо, веб-сокеты, да. Но браузеры запрещают подключаться к localhost / 127.0.0.1 по соображениям безопасности.
Поддельный указатель в виде DNS или hosts-файла на подобную поддомену local.game.tld плох, потому что SSL-сертификаты могут быть отозваны здесь как плохое использование.
Другой идеей было предоставить NPAPI-плагин для браузера. Но кажется, что NPAPI устарел и бесполезен в будущем.
Как лучше всего взаимодействовать между webpages локальными и установленными software ?
Ответ №1:
Но браузеры запрещают подключаться к localhost / 127.0.0.1 по соображениям безопасности
Это не так. Браузеры позволяют подключаться к localhost / 127.0.0.1. Я делаю это постоянно на своей машине.
Проблема в том, что для TLS ( wss://localhost , not ws://localhost ) требуется сертификат, а браузеры запрещают смешанный контент (вы не можете https загружать незашифрованные ресурсы на веб-сайт).
поддельный указатель в качестве DNS или hosts-файла на поддомен, такой как local.game.tld, плох, потому что SSL-сертификаты могут быть отозваны здесь как плохое использование.
В рамках программы установки игры вы можете создать hosts файловую запись с сертификатом для mygame.localhost (возможно, используя локальный скрипт), а затем попросить игрока авторизовать установку сертификата, используя его пароль. Таким образом, ваш сертификат не будет отозван… но вы правы, что это его неоптимально.
РЕДАКТИРОВАТЬ: также обратите внимание, что имя домена должно быть в конце, а не в начале (т. Е. game.localhost И не localhost.game ).
Как лучше всего взаимодействовать между веб-страницами и локально установленным программным обеспечением?
Вообще говоря, если ваша игра установлена на локальном компьютере, нет необходимости шифровать связь между локальным браузером и локальной машиной.
Вы можете легко настроить свой локальный сервер так, чтобы он принимал только соединения с локального компьютера (или, на худой конец, если потребуется, принимал соединения из локальной сети — хотя это добавляет риски безопасности).
Данные вашей веб-страницы и WebSocket могут быть отправлены «в открытом виде» ( ws:// и http:// ) между локальным сервером и браузером, поскольку они оба находятся на одном компьютере — таким образом, вам не нужен браузер. Локальный сервер будет инициировать (как клиент) любое зашифрованное соединение, которое ему требуется при обмене данными с внешней службой ( was:// / https:// ).
РЕДАКТИРОВАТЬ (из комментариев):
Есть только 2 решения, о которых я знаю:
-
Установка самозаверяющего сертификата; или
-
Используя
httpвместоhttpsи имея сервер, обрабатывающий внешний трафик, как если бы он был клиентом (поэтому весь трафик, выходящий наружу, зашифрован).
Комментарии:
1. К последним частям: веб-сайт всегда работает по протоколу https. Вы сказали то же самое: смешанный контент — это зло, то же самое с DNS-указателем. Но какова практика bes с этим? Я думаю, что исходный клиент из Electronic Arts использует ту же практику: самоподписанные сертификаты в локальном домене, например local.
<example.tld>2. @AdrianPreuss — я знаю только 2 решения: (1) установка самозаверяющего сертификата; (2) использование
httpвместоhttpsи сервер обрабатывает внешний трафик, как если бы он был клиентом (поэтому весь трафик, выходящий наружу, зашифрован).).