Сообщение Re[7]: Как странице в браузере найти сервер в локальной сети от 05.04.2021 14:42
Изменено 05.04.2021 15:07 Vetal_ca
Re[7]: Как странице в браузере найти сервер в локальной сети
Здравствуйте, Basil2, Вы писали:
B>А с local DNS это может прокатить? Например, сервер регистрирует в локальном DNS (mDNS) адрес server.local, и веб-клиент всегда обращается к адресу wss://server.local. Тогда сертификат нужен только один.
Можно, конечно. Локально можно крутить весь свой интернет с DNS, подсетями и TLS
Проблема в том, что у тебя будет самоподписанный certificate authority (CA), не включенный в глобальный, для *.local. Браузеры идут с существующими trusted root CA. И не только браузеры, еще клиентский код. Тот же curl.
См https://security.stackexchange.com/questions/158997/how-does-my-browser-inherently-trust-a-ca
В твоем случае, ты создаешь собственную PKI Infrastructure. Я использую для внутренних CA Vault PKI. Но можно при помощи openssl, конкретный лучший тьюториал я не подскажу.
Первый попавшийся: https://pki-tutorial.readthedocs.io/en/latest/
После этого, чтобы у пользователей не ругался браузер или клиентская часть, твой созданный CA нужно добавить в trusted root CA
https://en.wikipedia.org/wiki/Chain_of_trust
https://www.google.com/search?q=windows+add+trusted+root+ca
https://www.google.com/search?q=Linux+add+trusted+root+ca
Т.е., или свой CA и пользователи должны добавлять CA. Или DNS + сертификат внутри глобальной CA Trust Chain — "настоящий" сертификат.
Cертификат еще обновлять нужно. Let's Encrypt — 3 месяца.
Кстати, раздачу сертификатов можно через свой web сервис сделать, как часть платной подписки. Ну и, локальные DNS + Cert раздавать через его.
При этом наверняка будет еще проблема с DNS rebinding attack, многие раутеры по умолчанию будут препятствовать Public DNS Record -> Private IP
B>А с local DNS это может прокатить? Например, сервер регистрирует в локальном DNS (mDNS) адрес server.local, и веб-клиент всегда обращается к адресу wss://server.local. Тогда сертификат нужен только один.
Можно, конечно. Локально можно крутить весь свой интернет с DNS, подсетями и TLS
Проблема в том, что у тебя будет самоподписанный certificate authority (CA), не включенный в глобальный, для *.local. Браузеры идут с существующими trusted root CA. И не только браузеры, еще клиентский код. Тот же curl.
См https://security.stackexchange.com/questions/158997/how-does-my-browser-inherently-trust-a-ca
В твоем случае, ты создаешь собственную PKI Infrastructure. Я использую для внутренних CA Vault PKI. Но можно при помощи openssl, конкретный лучший тьюториал я не подскажу.
Первый попавшийся: https://pki-tutorial.readthedocs.io/en/latest/
После этого, чтобы у пользователей не ругался браузер или клиентская часть, твой созданный CA нужно добавить в trusted root CA
https://en.wikipedia.org/wiki/Chain_of_trust
https://www.google.com/search?q=windows+add+trusted+root+ca
https://www.google.com/search?q=Linux+add+trusted+root+ca
Т.е., или свой CA и пользователи должны добавлять CA. Или DNS + сертификат внутри глобальной CA Trust Chain — "настоящий" сертификат.
Cертификат еще обновлять нужно. Let's Encrypt — 3 месяца.
Кстати, раздачу сертификатов можно через свой web сервис сделать, как часть платной подписки. Ну и, локальные DNS + Cert раздавать через его.
При этом наверняка будет еще проблема с DNS rebinding attack, многие раутеры по умолчанию будут препятствовать Public DNS Record -> Private IP
Re[7]: Как странице в браузере найти сервер в локальной сети
Здравствуйте, Basil2, Вы писали:
B>А с local DNS это может прокатить? Например, сервер регистрирует в локальном DNS (mDNS) адрес server.local, и веб-клиент всегда обращается к адресу wss://server.local. Тогда сертификат нужен только один.
Можно, конечно. Локально можно крутить весь свой интернет с DNS, подсетями и TLS
Проблема в том, что у тебя будет самоподписанный certificate authority (CA), не включенный в глобальный, для *.local. Браузеры идут с существующими trusted root CA. И не только браузеры, еще клиентский код. Тот же curl.
См https://security.stackexchange.com/questions/158997/how-does-my-browser-inherently-trust-a-ca
В твоем случае, ты создаешь собственную PKI Infrastructure. Я использую для внутренних CA Vault PKI. Но можно при помощи openssl, конкретный лучший тьюториал я не подскажу.
Первый попавшийся: https://pki-tutorial.readthedocs.io/en/latest/
После этого, чтобы у пользователей не ругался браузер или клиентская часть, твой созданный CA нужно добавить в trusted root CA
https://en.wikipedia.org/wiki/Chain_of_trust
https://www.google.com/search?q=windows+add+trusted+root+ca
https://www.google.com/search?q=Linux+add+trusted+root+ca
Т.е.,
— или свой CA и пользователи должны добавлять CA.
— Или DNS + сертификат внутри глобальной CA Trust Chain — "настоящий" сертификат. Для настоящего поддомена, типа <some-user/prefix>.basil2.com
Cертификат еще обновлять нужно. Let's Encrypt — 3 месяца.
Кстати, раздачу сертификатов для второго случая можно через свой web сервис сделать, как часть платной подписки. Ну и, локальные DNS + Cert раздавать через его. Т.е., пользователь дает тебе внутренний IP (192.168. ....). А ты добавляешь Public DNS record сам (john123.basil2.com => 192.168...), генерируешь сертификат через Let'sEncrypt, с DNS Challenge, и отдаешь пользователю
При этом наверняка будет еще проблема с DNS rebinding attack, многие раутеры по умолчанию будут препятствовать Public DNS Record -> Private IP
Концептуально, весь этот гемор потому, что случай у тебя нестандартный: "инфраструктура на стороне пользователя". У классического, SaaS, инфраструктура с другой стороны.
Это и игры, и всякие домашние системы видеонаблюдения и прочие жирные потоки, которые не должны пересекать раутер
B>А с local DNS это может прокатить? Например, сервер регистрирует в локальном DNS (mDNS) адрес server.local, и веб-клиент всегда обращается к адресу wss://server.local. Тогда сертификат нужен только один.
Можно, конечно. Локально можно крутить весь свой интернет с DNS, подсетями и TLS
Проблема в том, что у тебя будет самоподписанный certificate authority (CA), не включенный в глобальный, для *.local. Браузеры идут с существующими trusted root CA. И не только браузеры, еще клиентский код. Тот же curl.
См https://security.stackexchange.com/questions/158997/how-does-my-browser-inherently-trust-a-ca
В твоем случае, ты создаешь собственную PKI Infrastructure. Я использую для внутренних CA Vault PKI. Но можно при помощи openssl, конкретный лучший тьюториал я не подскажу.
Первый попавшийся: https://pki-tutorial.readthedocs.io/en/latest/
После этого, чтобы у пользователей не ругался браузер или клиентская часть, твой созданный CA нужно добавить в trusted root CA
https://en.wikipedia.org/wiki/Chain_of_trust
https://www.google.com/search?q=windows+add+trusted+root+ca
https://www.google.com/search?q=Linux+add+trusted+root+ca
Т.е.,
— или свой CA и пользователи должны добавлять CA.
— Или DNS + сертификат внутри глобальной CA Trust Chain — "настоящий" сертификат. Для настоящего поддомена, типа <some-user/prefix>.basil2.com
Cертификат еще обновлять нужно. Let's Encrypt — 3 месяца.
Кстати, раздачу сертификатов для второго случая можно через свой web сервис сделать, как часть платной подписки. Ну и, локальные DNS + Cert раздавать через его. Т.е., пользователь дает тебе внутренний IP (192.168. ....). А ты добавляешь Public DNS record сам (john123.basil2.com => 192.168...), генерируешь сертификат через Let'sEncrypt, с DNS Challenge, и отдаешь пользователю
При этом наверняка будет еще проблема с DNS rebinding attack, многие раутеры по умолчанию будут препятствовать Public DNS Record -> Private IP
Концептуально, весь этот гемор потому, что случай у тебя нестандартный: "инфраструктура на стороне пользователя". У классического, SaaS, инфраструктура с другой стороны.
Это и игры, и всякие домашние системы видеонаблюдения и прочие жирные потоки, которые не должны пересекать раутер