On my main server, the one connected directly to the internet that redirects to LOCAL, already contains entries for each redirection in /etc/httpd/conf.d/virtualhosts.conf.
On the main server, do you mean:
Create a file that comes alphabetically beforevirtualhosts.conf
Copy the redirection sections from virtualhosts.conf to the new created file.
In the new created file, add the nocanon directive parameterat the end of the ProxyPass lines.
Correct me if Iâm wrong:
When the httpd daemon will look for the redirected port/ServerName, it will take the directives from the new file as it comes beforevirtualhosts.conf ?
On my LOCAL Chat server, I created an encrypted public Room.
On my connection to matrix.org, I Search for the created Room on LOCAL Chat server => Join.
My connection to matrix.org joined the Room on LOCAL Chat server without problem (which is a PremiĂšre).
Exchange a few chats between my Chat and matrix.org => both were fast to display the exchanges.
CONCLUSION:
It is the web redirections that canonicalise(replacing the characters)%40 , the %3A , etcâŠ
QUESTION:
Is it possible to do the same with this directive parameter as you did with X-Forwarded-Proto ?
Might be quite tricky as it is a parameter and not a full directive⊠But since you are adding max=3 and retry=30 parameters only in redirection sections, can you also add nocanon ?
Hello michel, yes we added new feature to proxypass, but I am not sure for the nocanon, because it might be risky as the apache documentation said, but you are right to ask for it because developers sometimes are in their ivory tower.
We added for now the X-Forwarded-Proto and soon the AllowEncodedSlashes NoDecode but for now without UI checkbox. Maybe with UI we could add another one to enable nocanon because I know nocanon works with AllowEncodedSlashes NoDecode.
In my dream night I would like to change a bit the UI and allow more complex proxypass feature, for now we just allow to do a reverse proxy from / to another http URL, and I would like to be able to this in the UI if needed
<VirtualHost *:443>
ServerName collabora.domain.com
SSLEngine on
# Encoded slashes need to be allowed
AllowEncodedSlashes NoDecode
# keep the host
ProxyPreserveHost On
# static html, js, images, etc. served from loolwsd
# loleaflet is the client part of LibreOffice Online
ProxyPass /loleaflet http://127.0.0.1:9980/loleaflet retry=0
ProxyPassReverse /loleaflet http://127.0.0.1:9980/loleaflet
# WOPI discovery URL
ProxyPass /hosting/discovery http://127.0.0.1:9980/hosting/discovery retry=0
ProxyPassReverse /hosting/discovery http://127.0.0.1:9980/hosting/discovery
# Main websocket
ProxyPassMatch "/lool/(.*)/ws$" ws://127.0.0.1:9980/lool/$1/ws nocanon
# Admin Console websocket
ProxyPass /lool/adminws ws://127.0.0.1:9980/lool/adminws
# Download as, Fullscreen presentation and Image upload operations
ProxyPass /lool http://127.0.0.1:9980/lool
ProxyPassReverse /lool http://127.0.0.1:9980/lool
# Endpoint with information about availability of various features
ProxyPass /hosting/capabilities http://127.0.0.1:9980/hosting/capabilities retry=0
ProxyPassReverse /hosting/capabilities http://127.0.0.1:9980/hosting/capabilities
</VirtualHost>
I think it is more a security concern in the application backend because the url are given to the proxy without more verifications. At least this is what the apache documentation says
I agree: adding always nocanon is a bad security practice.
Sorry but I disagree on this. The UI should focus on user task, not on exposing all possible configurations. If the user needs more control on a specific proxy pass there are 2 alternatives:
add a template-custom (hard)
drop a configuration file inside /etc/http/conf.d (easy)
Iâm always against overloading the UI with complex and too-specific features.
Since the beginning NethServer 7 attempts to integrate with the upstream Apache configuration in a seamless way: it should be easy to add a third-party webapp integration by just following its Apache guidelines for CentOS.
That means, to integrate a third-party webapp with a complex setup (like Collabora):
drop the .conf file (copied from the guidelines) in /etc/httpd/conf.d/
add it to custom backup inclusions: /etc/backup-config.d/custom.include
If your dream becomes true and we overload the UI, the procedure for the sysadmin becomes
fully understand the Apache app guidelines
fully understand the complex UI (uh, what does this option actually do?)
logically map the above knowledges
configure the complex UI
And the procedure for the developer becomes a nightmare
fully understand every Apache feature
implement the UI in a coherent way
document what it does, so experts and non-experts can understand
give more and more details when support requests come
Template-custom:
Which one for the Redirection inside virtualhosts.conf ?
You have to find the file dealing with retry=30 then add nocanon.
This paramenter will then affect all new virtualhost creations and maybe itâs not what itâs wanted.
With a file in conf.d:
This is not easy with Redirection. You have to copy /etc/httpd/conf.d/virtualhosts.conf to /etc/httpd/conf.d/u_nocanon.conf, delete some sections, then add nocanon and restart httpd. This will affect only the already created redirections.
I would like to know exactly what is the risk here with nocanon.
The LOCAL server will receive the same exact packet as the NS proxy server and will process it the same way. If itâs dangerous for the LOCAL server, itâs also as dangerous for the proxy server.
If itâs the destination app, then itâs the same app running on the LOCAL server.
The problem with phishing is between the chair and the mouse, not with the OSâŠ
If itâs on the UI, then it is possible to add âSecurity riskâ beside the check box.
Also, there is the help button which can display an explaination.
Itâs not an easy task but it should be possible to do something.
Sonatype server products do not rely on reverse proxies to filter out suspect URLs containing path info with encoded values, so it is OK to use ânoncanonâ with Nexus Repository Manager.
Itâs nocanon not 'noncanon"⊠and what is that âNexus Repository Managerâ ?
The real threat is nowhere to be found.
If the Matrix-Synapse FEDERATION is using it, there should be a reason and maybe they check it the same way as SonatypeâŠ
I retested matrix synapse successfully with reverse proxy and created /etc/httpd/conf.d/a_synapse.conf on the âmainâ Nethserver to reverse proxy both, port 443 and 8448 with nocanon option to the local VM (1.2.3.4 in this example). You also need to open port 8448 on the âMainâ Nethserver by creating a service âsynapseâ with TCP port 8448 and access for red and green. This way no reverse proxy in cockpit is needed.
Thereâs a pfsense firewall in front, port forwarding to the âMainâ NethServer but from there itâs a similar case.
Yes, in my case itâs a VMWare VM.
No, yourdomain.org is the domain name of the âMainâ server in my case. I think itâs not relevant in our case as weâre working with custom named reverse proxies.
As itâs my test VM I have a local DNS entry for testserver.domain.local. I think itâs not needed because we use yourdomain.org.
No port forwarding, just reverse proxy.
Yes, 1.2.3.4 is the private IP of the local VM, sorry for confusionâŠ
Yes, it does, by reverse proxying traffic to the local VM.
No, I have a working LE cert on both but only the LE cert on the main server is used.
No.
Itâs unchanged on both main server and local vm, acme-challenge only.
[root@server2 ~]# ls /var/www/html/.well-known/
acme-challenge
Yes, maybe reload would be enough too.
Yes, for searching/joining the room I needed to enter the full room name including domain but joining wasnât an issue at all. Invitation worked too from and to the local VM.