Add support for Unix sockets for Web Service and DoH

[IngmarStein]

This adds support for listening on Unix domain sockets in addition to TCP ports for both the Web Service (HTTP/HTTPS) and DNS-over-HTTPS (DoH).

Unix sockets are often used for these reasons:

• Secure Local IPC: They allow secure, high-performance connections from a local reverse proxy (like Nginx or HAProxy) without exposing the service on local TCP ports, which could be accessible to other local users or processes.
• Performance: They avoid the overhead of the TCP/IP networking stack (routing, packet encapsulation, etc.), leading to lower latency and higher throughput for proxy setups.
• Security: Access to Unix sockets can be strictly controlled using standard file system permissions (chown/chmod), providing an additional layer of security over local TCP loopback binding.

The configuration has been updated to support a single Unix socket path for HTTP and HTTPS variants of the Web UI and DoH services.

[ShreyasZare]

Thanks for the PR. Will review it soon.

[IngmarStein]

@ShreyasZare what's your position on this feature? If you're positive, I'll go ahead and resolve the merge conflicts with current HEAD.

[ShreyasZare]

@ShreyasZare what's your position on this feature? If you're positive, I'll go ahead and resolve the merge conflicts with current HEAD.

Thanks for asking. Yes, this is useful option to have. Just could not find enough time to include this in the latest release. Would be nice if you can resolve the conflicts.

Another thing I had in mind regarding this is that unix socket for TLS will probably be not useful since reverse proxy setups tend to do TLS termination. So, having it for plain HTTP will be good I think unless you know some application that requires TLS support with unix sockets.

[IngmarStein]

Alright, thanks for the feedback, I'll resolve the conflicts then.

Another thing I had in mind regarding this is that unix socket for TLS will probably be not useful since reverse proxy setups tend to do TLS termination. So, having it for plain HTTP will be good I think unless you know some application that requires TLS support with unix sockets.

Most reverse proxies (at least Caddy, Nginx, Pomerium) these days allow TLS also for their backend / upstream connections and also over UDS. For example:

Caddy:

example.com {
    reverse_proxy unix//run/my-app.sock {
        transport http {
            tls
            tls_server_name upstream.internal
        }
    }
}

Nginx:

    location / {
        proxy_pass https://unix:/run/my-app.sock;
        proxy_ssl_server_name on;
        proxy_ssl_name upstream.internal;
    }

HAproxy:

backend secure_unix_socket
    mode http
    
    server app_node_1 /run/my-app.sock ssl verify none sni str(upstream.internal)

TLS can help with HTTP/2 for when h2c is not available. I think having that option doesn't hurt.
Many applications like Grafana, Miniflux, Paperless-ngx also support it.

[IngmarStein]

@ShreyasZare it's ready for another look

[ShreyasZare]

Thanks for the changes. Will review them soon.

Most reverse proxies (at least Caddy, Nginx, Pomerium) these days allow TLS also for their backend / upstream connections and also over UDS. For example:

The reason I think TLS option wont be useful is that unix sockets used on local host and thus TLS on the same host may not add any value in terms of security. Additional option may confuse some users too.

[IngmarStein]

Some application support simultaneous dual-serving over TCP and UDS and once you enable TLS (for HTTPS), they also expect that over UDS. I think it's logically useful to decouple

• transport: TCP vs UDP
• encryption: TLS or plain-text
  And then to allow all possible combinations, rather than restricting some. But obviously, that's up to you.