Можно ли как-нибудь разрешить такое соединение?
Это форма активный смешанный контент . Все последние браузеры, , такие как Firefox и Google Chrome, запрещают этот тип контента, так же как они запрещают защищенной странице (загруженной HTTPS) загружать небезопасный JavaScript.
Аргументация довольно проста: она в первую очередь подрывает цель HTTPS.
«Правильный» способ исправить это состоит в том, чтобы заставить все третьи стороны использовать HTTPS на своих веб-сокетах и избежать всей проблемы.
Один из таких способов - позволить посреднику также быть прокси
Да. Вы можете настроить прокси-сервер для своих третьих лиц, для которого вы хотите разрешить прокси. Есть множество примеров такого nginx, разбросанных по всему интернету. Простой пример может быть:
# untested configuration
server {
listen 443 ssl;
ssl_certificate /etc/ssl/certs/cert.pem;
ssl_certificate_key /etc/ssl/private/cert.key;
location /3rdpartyproxy {
proxy_pass http://203.48.15.199:3422;
proxy_http_version 1.1;
proxy_set_header Upgrade websocket;
proxy_set_header Connection upgrade;
}
}
Нечто подобное может работать, но имейте в виду, что это не в интересах ваших пользователей. Соединение между вашим прокси и сторонним поставщиком по-прежнему небезопасно и уязвимо для всех тех же атак, что и обычный HTTP.
Еще одна вещь, на которую следует обратить внимание, это убедиться, что ваш прокси не используется некорректно другими сторонами. Я видел, как некоторые люди устанавливали прокси с динамическим путем и передавали этот трафик куда угодно. Что-то вроде:
ws://myproxy.example/203.48.15.199/3422
Затем настройте веб-сервер так, чтобы он подключался к любому URL-адресу. Это кажется хорошим решением, потому что оно будет делать правильные вещи в зависимости от того, какой URL есть. Основным недостатком является то, что если у вас нет какой-либо аутентификации для прокси, любой может использовать ее для прокси-трафика в любом месте.
Подведем итог:
- Вы не можете разрешить ws: на https: страниц.
- Лучшее решение - перенести бремя на третьих лиц. Настройте надлежащие HTTPS. Это наиболее выгодно, поскольку оно полностью служит цели HTTPS.
- В может прокси это. Предостережение заключается в том, что он по-прежнему небезопасен от вашего прокси-сервера до третьей стороны, и теперь вам нужно управлять прокси-сервером. Nginx делает это довольно легко.
- Если вы идете по прокси-маршруту, убедитесь, что он настроен таким образом, что его нельзя злоупотреблять.
Если мне требуется SSL, означает ли это, что они не смогут просто опубликовать IP-адрес для подключения?
Для получения сертификата HTTPS требуется доменное имя. Точнее, получить сертификат для IP-адреса возможно , но это очень необычно и требует гораздо больше усилий, чем получение сертификата для доменного имени.
Насколько больше это бремени?
Это в основном вопрос мнения, но это будет означать выбор домена, его регистрацию и оплату за регистрацию у регистратора. Стоимость варьируется, но домен обычно можно купить менее чем за 15 долларов в год, если в этом домене нет ничего особенного.
Может ли процесс раскрытия HTTPS быть полностью автоматическим?
Получение сертификата HTTPS в основном автоматизировано. Let's Encrypt предлагает HTTPS-сертификаты бесплатно (действительно, бесплатно, без всяких строк, теперь очень популярный центр сертификации). Их подход немного другой. Они выдают 3-месячные сертификаты, но используют программное обеспечение под названием CertBot , которое автоматизирует продление и установку сертификата. Поскольку процесс полностью автоматизирован, срок действия сертификата на самом деле не имеет значения, поскольку все автоматически обновляется в фоновом режиме.
Существуют другие веб-серверы, которые используют этот шаг дальше. Apache теперь поддерживает ACME (протокол, который использует Let's Encrypt). Caddy - еще один веб-сервер, который доводит конфигурацию HTTPS до предела простоты.
Для ваших третьих лиц вы можете рассмотреть возможность предоставления им примеров конфигурации, в которых HTTPS правильно настроен для различных веб-серверов.
Мне бы хотелось немного больше описать возможность "сертификаты для IP-адресов", так как я чувствую, что вы не заметили это.
IP-адреса для сертификатов возможны, но они чрезвычайно редки для общедоступных веб-сайтов. https://1.1.1.1 - недавний пример.
В конечном счете, ЦС должен подтвердить, что Проверяющая сторона (физическое лицо или организация, запрашивающая сертификат) может продемонстрировать контроль над IP-адресом. В разделе 3.2.2.5 Требования CA / B описывается, как это делается, но практически СА остается за проверкой владения IP-адресом. Таким образом, сертификаты «Проверка домена» не имеют права на сертификаты с IP-адресами. Вместо этого, как минимум, необходимы сертификаты «Организация подтверждена», или OV. Оформление сертификата OV является более строгим и не может быть автоматизировано. Помимо подтверждения права собственности на IP-адрес, вам потребуется предоставить документацию, удостоверяющую личность проверяющей стороны, например, водительские права для физического лица или налоговые документы для организации.
Let's Encrypt не выдает сертификаты для IP-адресов, поэтому вам, вероятно, придется найти другой центр сертификации, который их выдаст, и, вероятно, заплатит за них. Регистрация доменного имени для IP-адреса, скорее всего, окажется более экономически эффективной.
Я не знаю ни одного ЦС, который будет выдавать сертификаты для IP-адреса в автоматическом режиме, например Let's Encrypt / CertBot.
Использование доменного имени обеспечивает большую гибкость. Если необходимо изменить IP-адрес, то достаточно просто обновить записи A / AAAA в DNS. Если сертификат предназначен для IP-адреса, то необходимо будет выдать новый сертификат.
В некоторых программах и браузерах были исторические проблемы совместимости с IP-адресами в сертификатах.