Verarbeitet Apache ProxyPass auch TLS für Websockets?

Verarbeitet Apache ProxyPass auch TLS für Websockets?

Ich bin neu bei Proxypass. Nehmen wir an, dies ist unsere Konfiguration:

<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

Da wir diese Apache zur Verfügung gestellt haben

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/Wir müssen sie auch nicht im laufenden WebSocket-Server verwenden , ist das richtig?

Obwohl wir das tun können, kümmert sich Apache darum, oder? Und es ist redundant, es zweimal zu tun, insbesondere, da es sich um einen lokalen Server handelt, denke ich. Ich denke, wenn wir das tun, ws://127.0.0.1:1080/ray/müssen wir es tun wss://127.0.0.1:1080/ray/und innerhalb dieses WebSocket-Servers müssen wir dieselben Zertifikatsschlüssel bereitstellen.

Antwort1

Die Verwendung von ProxyPass zum Proxy zu einem ungesicherten Listener auf dem lokalen Host kann immer noch eine Angriffsfläche bieten. Befürchten Sie, dass jemand den Datenverkehr auf dem lokalen Host abhört? Wenn ich ein böswilliger Mensch mit den entsprechenden Zugriffsrechten wäre, könnte ich auf der Loopback-Schnittstelle auf Port 1080 einen TCP-Dump ausführen und den Datenverkehr lesen. Wenn Sie wss:// verwenden, wäre dies schwieriger. Ich würde TLS auf beiden Links verwenden, es sei denn, es gibt einen technischen Grund, dies nicht zu tun, oder wenn ich die Anwendung debuggen würde und während dieses Vorgangs weitere Informationen benötigen würde.

Antwort2

Ich kann meinen Senf dazugeben.

Konzentrieren wir uns auf <LocationMatch "/ray/">. Wie soll Apache den Pfad erkennen /ray/, wenn er in einem TLS-verschlüsselten Kanal gekapselt ist? Natürlich muss Apache TLS verarbeiten, um den HTTP-Handshake zu entschlüsseln und zu sehen und GET /whatever/dann zu entscheiden, ob es mit dem Standort übereinstimmt.

verwandte Informationen