Disable Web Sockets

Help
1

1. The problem I’m experiencing:

I’m in a situation where bidirectional tunnels won’t work. A SSL mitm proxy breaks the SSL tunnel, with a locally installed root cert keeping all connections as trustworthy.

I wonder if disabling web sockets (WSS or WS) would help. Normal SSL connections work, but the chain is broken due to mitm.

I assume, or hope, that if the connection is not upgraded and the web applications fall back to non websocket communication (which the ones I’m trying out appear to offer), that I can still use these services even with SSL inspection between server and client

2. Error messages and/or full log output:

Firefox kann keine Verbindung zu dem Server unter wss://domain.tld/ws aufbauen.
Which translates to the Browser cannot reach the server

3. Caddy version:

v2.8.5

4. How I installed and ran Caddy:

Opnsense plugin for caddy
os-caddy - version 1.5.7

a. System environment:

Opnsense - FreeBSD

b. Command:

Integrated into Opnsense UI as Service

c. Service/unit/compose file:

d. My complete Caddy config:

Caddyfile

# DO NOT EDIT THIS FILE -- OPNsense auto-generated file


# Global Options
{
	grace_period 10s
	import /usr/local/etc/caddy/caddy.d/*.global
}

# Reverse Proxy Configuration


import /usr/local/etc/caddy/caddy.d/*.conf

global.global

        acme_dns cloudflare <redacted>

        order replace after encode
        servers {
                trusted_proxies static private_ranges
                trusted_proxies static 192.168.10.1/32
                trusted_proxies cloudflare
        }

infra.conf

blog.wxbu.de, blog.wxbu.de, blog.grundstil.de, blog.wxbu.de {
        encode zstd gzip
        reverse_proxy caddydockerinfra.home.arpa {
                header_up X-Real-IP {client_ip}
                #header_up Host {http.reverse_proxy.upstream.host}
        }
}

access.wxbu.de, access.grundstil.de, access.amonsul.net {
        encode zstd gzip
        reverse_proxy guacamole:8080
}

neo.wxbu.de, neo.grundstil.de, neo.amonsul.net {
  reverse_proxy neo:8080 {
    header_up Host {host}
    header_up X-Real-IP {remote_host}
    header_up X-Forwarded-For {remote_host}
    header_up X-Forwarded-Proto {scheme}
  }
}
2

Please completely fill out the help topic template as per the forum rules. We don’t really have enough context here. What’s your current config? What’s in your logs?

I don’t understand the problem you’re trying to solve. Why would blocking specific kinds of requests solve anything? You already get an error, so making it a different kind of error wouldn’t really do anything useful I would think.

1 Like
3

Sorry, I missed attaching the config files.
I assume that web sockets, or anything that requires a persistent tunnel between client and server, is suppressed. RDP or WebRTC therefore also won’t work - due to the SSL inspection, the man in the middle breaks the tunnel.

Classical TCP mono-directional services do work, so I want to prevent connection upgrades to bidirectional tunnels to see if that enables those services affected.

4

That won’t work, only the last trusted_proxies will take effect. If you need to combine IP ranges, you need GitHub - fvbommel/caddy-combine-ip-ranges: IP prefix module for Caddy that combines the output of other IP prefix modules.

That’s not necessary, Caddy already passes it through as X-Forwarded-For.

Remove all this. It’s garbage.

Anyway, I still don’t understand your problem statement. If websockets are already failing to work (as you said “Browser cannot reach the server”) then why do you think you need to “disable websockets”? The logic doesn’t make sense to me here.

I feel like there’s context lacking here. I’ve read through your post a few times and I don’t understand what you’re trying to do.

1 Like
5

Thank you for your input. Good to learn that just the last trusted_proxies directive is used, I wondered how combining private_ranges and cloudflare ranges work.

But back on topic:
Some applications, like nextcloud or guacamole, can make use of websockets to improve performance, but also work “fine” without.

In the default setting, caddy enables connections upgrades to allow streaming connections. I understand this as bi-directional tunnels. This is then what breaks.

The SSL inspection Firewall works by putting a trusted root certificate into the system of a client. Any SSL connection is thus trusted on the client with a certificate signed by the root authority of the Firewall. Not with the certificate by the original issuing entity, for example one of my services with a caddy delivered TLS cert.

The Firewall acts as an SSL proxy. It may do some packet inspection to protect the network, too. RDP and WebRTC don’t work, so I think it blocks what it cannot look into.

Since those parts of Nextcloud which don’t rely on websockets work and the rest is capable to deal with a non-websocket environment, I wonder if caddy can be configured to suppress connection upgrades.

6

Where is this firewall? In front of Caddy, or behind Caddy? Because if it’s in front of Caddy, the websocket connections will already broken before it reaches Caddy anyway (so there’s nothing valid to do in Caddy). If it’s behind Caddy, then wat ? This setup doesn’t make sense to me.

You haven’t shown any evidence of the problem you’re trying to solve. You haven’t shown any relevant Caddy logs etc. Enable the debug global option in Caddy and show your logs.

1 Like
7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.