☰

Обрабатывает ли Apache ProxyPass TLS для WebSocket?

tag-icon • tag-icon reverse-proxy apache2 websocket
Обрабатывает ли Apache ProxyPass TLS для WebSocket?

Я новичок в proxypass. Допустим, вот наша конфигурация:

<IfModule mod_ssl.c>
<VirtualHost *:443>
        # The ServerName directive sets the request scheme, hostname and port that
        # the server uses to identify itself. This is used when creating
        # redirection URLs. In the context of virtual hosts, the ServerName
        # specifies what hostname must appear in the request's Host: header to
        # match this virtual host. For the default virtual host (this file) this
        # value is not decisive as it is used as a last resort host regardless.
        # However, you must set it for any further virtual host explicitly.
        #ServerName www.example.com

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html

        # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
        # error, crit, alert, emerg.
        # It is also possible to configure the loglevel for particular
        # modules, e.g.
        #LogLevel info ssl:warn

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined

        # For most configuration files from conf-available/, which are
        # enabled or disabled at a global level, it is possible to
        # include a line for only one particular virtual host. For example the
        # following line enables the CGI configuration for this host only
        # after it has been globally disabled with "a2disconf".
        #Include conf-available/serve-cgi-bin.conf


ServerName www.xzos.net
Include /etc/letsencrypt/options-ssl-apache.conf
ServerAlias xzos.net
SSLCertificateFile /etc/letsencrypt/live/www.xzos.net/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.xzos.net/privkey.pem

<LocationMatch "/ray/">
        ProxyPass ws://127.0.0.1:1080/ray/ upgrade=WebSocket
        ProxyAddHeaders Off
        ProxyPreserveHost On
        RequestHeader set Host %{HTTP_HOST}s
        RequestHeader set X-Forwarded-For %{REMOTE_ADDR}s
</LocationMatch>
</VirtualHost>
</IfModule

Так как мы предоставили их Apache

SSLCertificateFile /etc/letsencrypt/live/www.xzos.net/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/www.xzos.net/privkey.pem

Нам не нужно использовать их ws://127.0.0.1:1080/ray/также на сервере веб-сокетов, верно?

Хотя мы можем это сделать, но Apache справляется с этим, верно? и это излишне делать это дважды, особенно, поскольку это локальный сервер, я полагаю. Я думаю, если мы это сделаем, то ws://127.0.0.1:1080/ray/нужно будет стать wss://127.0.0.1:1080/ray/и внутри этого сервера веб-сокетов мы предоставим те же ключи сертификатов.

решение1

Использование proxyPass для проксирования на незащищенный прослушиватель на localhost все еще может раскрыть поверхность атаки. Вас беспокоит, что кто-то прослушивает трафик на localhost? Если бы я был подлым человеком с соответствующим доступом, я мог бы выполнить tcpdump на интерфейсе loopback на порту 1080 и прочитать трафик. Если вы используете wss://, то это будет сделать сложнее. Я бы использовал TLS на обеих ссылках, если только нет технических причин не делать этого или если бы я отлаживал приложение и мне нужно было получить больше информации в ходе этого процесса.

решение2

Могу добавить свои пять копеек.

Давайте сосредоточимся на <LocationMatch "/ray/">. Как Apache должен распознать путь /ray/, если он инкапсулирован в зашифрованный канал TLS? Конечно, Apache должен обрабатывать TLS, чтобы расшифровать http-рукопожатие и посмотреть GET /whatever/, а затем решить, соответствует ли оно местоположению.

Связанный контент