☰

¿Apache ProxyPass también maneja tls para websocket?

tag-icon • tag-icon reverse-proxy apache2 websocket
¿Apache ProxyPass también maneja tls para websocket?

Soy nuevo en proxypass. Digamos que esta es nuestra configuración:

<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

Desde que proporcionamos estos a Apache

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

No deberíamos necesitar usarlos ws://127.0.0.1:1080/ray/también en el servidor websocket que se ejecuta, ¿es correcto?

Aunque podemos hacer eso, Apache lo maneja, ¿verdad? y supongo que es redundante hacerlo dos veces, especialmente porque se trata de un servidor local. Creo que si hacemos eso, entonces ws://127.0.0.1:1080/ray/debemos hacerlo wss://127.0.0.1:1080/ray/y dentro de ese servidor websocket proporcionamos las mismas claves de certificado.

Respuesta1

El uso de proxyPass para representar a un oyente no seguro en localhost aún puede exponer una superficie de ataque. ¿Le preocupa que alguien esté husmeando el tráfico en localhost? Si fuera una persona nefasta con el acceso adecuado, podría tcpdump en la interfaz loopback en el puerto 1080 y leer el tráfico. Si usa wss:// entonces sería más difícil hacerlo. Usaría TLS en ambos enlaces a menos que haya una razón técnica para no hacerlo o si estuviera depurando la aplicación y necesitara obtener más información durante ese proceso.

Respuesta2

Puedo añadir mis dos centavos.

Centrémonos en <LocationMatch "/ray/">. ¿Cómo se supone que Apache reconozca la ruta /ray/si está encapsulada en un canal cifrado TLS? Por supuesto, Apache tiene que manejar TLS para descifrar el protocolo de enlace http y ver GET /whatever/, luego decidir si coincide con la ubicación.

información relacionada