Mailing-List: contact dev-help@community.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@community.apache.org
From: tvb@able.be
To: dev@community.apache.org
Reply-To: tvb@able.be
Subject: mod_proxy_wstunnel incomplete handshake
Date: Tue, 08 Mar 2016 17:28:34 +0100
Message-ID: <6018550.Zyo3QNZvLY@itsj>
User-Agent: KMail/4.14.10 (Linux/4.4.0-gentoo-r1-itsj; KDE/4.14.16; x86_64; ;
 )
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="nextPart7419041.MaNBKHgbGY"
Content-Transfer-Encoding: 7Bit

--nextPart7419041.MaNBKHgbGY
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="iso-8859-1"

Hi,

I'm currently testing a Web socket application behind an apache reverse 
proxy. I started off with apache version 2.4.12, but after some weird 
behavior decided to test versions 2.4.16, 2.4.18 and latest svn.

https://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html[1] 
says that

"It provides support for the tunnelling of web socket connections to a 
backend websockets server. The connection is automatically upgraded 
to a websocket connection".

Consider the following config, where reverse proxy listens on 
192.168.0.1 port 80 and web socket application is hosted on internal 
web server 192.168.15.233 port 8888.

LoadModule proxy_module          modules/mod_proxy.so 
LoadModule proxy_wstunnel_module 
modules/mod_proxy_wstunnel.so

Listen 192.168.0.1:80 


    Servername test-ws.domain.org

    ProxyRequests Off 


    RewriteRule ^/([a-zA-Z0-9\.\_\ -:/]*)$  ws://192.168.15.233:8888/$1 [P]

    RewriteRule     .* - [F]

    ProxyPass / ws://192.168.15.233:8888/
    ProxyPassReverse / ws://192.168.15.233:8888/

</VirtualHost>

>From reading the docs it appeared as if HTTP requests are processed 
as normal, unless it is requested to upgrade it to a web socket. 
Basically in apache 2.4.12 the above config expects everything to be a 
web socket. The first request on a connection is processed as normal, 
but once considered a web socket, data is proxied as is without any 
further processing.

On 2.4.18 the behavior is different, only requests with the "Upgrade: 
Websocket" present are considered valid, any other request is denied 
stating unsupported protocol.


For instance:

$ telnet 192.168.0.1 80
Trying 192.168.0.1... 


The error log shows: 

"[Mon Mar 07 11:26:03.133185 2016] [proxy:warn] [pid 26745] [client 
192.168.0.1:33296] AH01144: No protocol handler was valid for the URL 
/. If you are using a DSO ve


The source code also reads that only the request is considered, and a 
response of the server is not/never expected. The only expectation is 
that the connection is opened at both sides (and readable), where it 
should expect a response to complete the handshake of the HTTP 
upgrade mechanism.

Any success or failure of the web server is not considered, eg. in 
success situations a 101 "Switching protocols" can be expected, any 
error status code to indicate a failure. Moreover this allows anyone to 
open a (secure) tunnel towards the back-end server, and possibly 
request anything (other) through it without apache noticing or notifying 
about it (no access/error logs).

Consider the following configuration on 2.4.18:

LoadModule proxy_module          modules/mod_proxy.so 
LoadModule proxy_wstunnel_module 
modules/mod_proxy_wstunnel.so

Listen 192.168.0.1:80 


    Servername test-ws.domain.org

    ProxyRequests Off 


    RewriteRule ^/(TEST/[a-zA-Z0-9\.\_\ -:/]*)$ 
 ws://192.168.15.233:8888/$1 [P]
    RewriteRule ^/[a-zA-Z0-9\.\_\ -:/]*)$  http://192.168.15.233:8888/$1 [P]

    RewriteRule     .* - [F]

    ProxyPass /TEST/ ws://192.168.15.233:8888/TEST/
    ProxyPassReverse /TEST ws://192.168.15.233:8888/TEST/

    ProxyPass / ws://192.168.15.233:8888/
    ProxyPassReverse / ws://192.168.15.233:8888/

</VirtualHost>

$ telnet 192.168.0.1 80

HTTP/1.1 404 Not Found 


HTTP/1.1 200 OK 
                                                                                                                                  
                    
The access log is empty, no trace of any failure. Still the connection is 
persistent and tunneling is further allowed.


The error log shows :
[Tue Mar 08 12:58:31.391351 2016] [rewrite:trace1] [pid 5988] 
mod_rewrite.c(476): [client 192.168.0.1:34207] 192.168.0.1 - - 
[192.168.0.1/sid#8c95ed8][rid#8cf0130/initial] go-ahead with proxy 
request proxy:wss://192.168.15.233:8888/TEST/anyapp [OK] [Tue Mar 
08 12:58:31.391726 2016] [ssl:info] [pid 5988] [remote 
192.168.15.233:8888] AH01964: Connection to child 0 established 
(server 192.168.0.1:80)


Later when the connection is terminated or times out, the access log 
shows:

192.168.0.1 - - [08/Mar/2016:12:58:30 +0100] "GET /INS-
AWINGU/anyapp HTTP/1.1" 200 -

Shouldn't there be some additional processing that at least completes 
the HTTP upgrade handshake before opening the tunnel permanently. If 
not, connections are left open and can be reused for other purposes.

Kind regards,
Tijs

--nextPart7419041.MaNBKHgbGY--