Bug 64810 - Unable to proxy requests to a secured websockets (wss) in 2.4.41
Summary: Unable to proxy requests to a secured websockets (wss) in 2.4.41
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_proxy_wstunnel (show other bugs)
Version: 2.4.41
Hardware: Other Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Depends on:
Reported: 2020-10-13 13:08 UTC by Orlando Ballon
Modified: 2021-01-19 13:23 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Orlando Ballon 2020-10-13 13:08:46 UTC
I have the following setup for a vnc service:
- vnc client : noVNC (0.6.1)
- vnc server : libvncserver (0.9.12)

When the noVNC client is launched, it will be re-directed and be served over secured layer, 'https://host/novnc.html?path=vnc'. Then this connection will be proxy'd to 'wss://localhost:5901':  ProxyPass /vnc wss://localhost:5901/
Then the expected upgraded to a websocket connection will happen.

In 2.4.41, the vnc server acknowledges a TLS/SSL Websockets Connection but then it will eventually report an 'invalid client header'. Also used noVNC 1.1.0 client and this issue is still encountered.
This was working since 2.4.29, up until 2.4.39. Also tested using the recent release - 2.4.46, and this wss connection still happens.

Best regards.
Comment 1 Orlando Ballon 2020-10-13 13:12:47 UTC
Btw, serving the vnc connection over regular websockets (ws) works as expected.

Comment 2 Orlando Ballon 2020-10-27 07:47:31 UTC
I continued the investigation on this issue, and was able to determine the change that affected the 'wss' proxy to fail in my vnc connection setup.
With the introduction of the change below, the previously working 'wss' proxy encountered a failure:
commit 7d272e2628b4ae05f68cdc74b070707250896a34
Author: Yann Ylavic <ylavic@apache.org>
Date:   Fri May 24 07:54:42 2019 +0000

    Merge r1818726 from trunk:

    mod_proxy: allow SSLProxyCheckPeer* usage for all proxy modules.

    PR 61857.

When this change was manually reverted in my local apache 2.4.41 setup, the 'wss' proxy is a success, and the vnc connection over 'wss' will work.

That's all for now. Thanks.
Comment 3 Yann Ylavic 2020-10-27 10:30:44 UTC
Does setting "SSLProxyCheckPeerName off" help?
This was always the case before the change in 2.4.41, now it's "on" by default like for other proxy modules.

The goal of this change was only to allow for peer certificate CN verification in all proxy modules, I overlooked that existing wss configurations with a non-matching certifcate would now fail because of the check by default..
Comment 4 Orlando Ballon 2020-10-28 09:10:37 UTC
Thank you for the information.

I set the "SSLProxyCheckPeerName off" in the httpd.conf and it does resolve the issue.

Below is the workflow of my vnc service setup:
1. Launch my site over http, and starts the vnc server (libvncserver).
2. click a button to launch noVNC client.
3. The url will be re-directed and be served over https, 'https://host/novnc.html?path=vnc'.
4. This will be proxy'd to 'wss://localhost:5901' per httpd.conf :
    ProxyPass /vnc wss://localhost:5901/
5. A prompt to accept a security exception to the site will show, and accepting the exception, the 'wss' connection will be a success.

However, when I launched my site over https, the vnc connection over wss will fail.
So, in step #1, the site is launched over https, and a prompt to accept a security exception to the site will show. After accepting the exception, step #5 will not prompt anymore but the vnc connection will fail. Have no details yet on this case but when I use the reverted option, this case where the site is launched over https, will still have a successful vnc connection over wss.

That's all for now. Thanks.
Comment 5 Orlando Ballon 2020-10-29 14:22:40 UTC
I continued investigating on the other case wherein my site is launched over https and then the vnc connection over wss was not a success. I made some minor tweak related to the re-direct of the noVNC url to https path, and it fixed the issue.

In summary, the additional directive - "SSLProxyCheckPeerName off" in my apache config file resolved the vnc connection to be successfully served over wss.

Thanks for the help.