Block every connections from unknown domains

[Nicryc (Nicolas)]

1. Caddy version (caddy version):

2.4.6

2. How I run Caddy:

a. System environment:

Windows 10

b. Command:

.\caddy.exe run

c. Service/unit/compose file:

I’m using WinSW to run Caddy as a service in Windows. Here’s my config file for the service.

<service>
  <id>caddy</id>
  <!-- Display name of the service -->
  <name>Caddy Web Server (powered by WinSW)</name>
  <!-- Service description -->
  <description>Caddy Web Server (https://caddyserver.com/)</description>
  <executable>%ProgramFiles%\Caddy\caddy.exe</executable>
  <arguments>run</arguments>
  <logpath>logs</logpath>
  <log mode="roll-by-time">
    <pattern>yyyy-MM-dd</pattern>
  </log>
</service>

d. My complete Caddyfile or JSON config:

test.duckdns.org {
	reverse_proxy localhost:8096
}

:80, :443, https://, http:// {
	abort
}

3. The problem I’m having:

I’d like to block and abort all connections from an undefined domain, for example when just entering my public IP address instead of the domain name in my Caddyfile.

What I did works on port 80 in HTTP but doesn’t in HTTPS on port 443, I’m getting a SSL_ERROR_INTERNAL_ERROR_ALERT instead of a The connection was reset.

4. Error messages and/or full log output:

SSL_ERROR_INTERNAL_ERROR_ALERT in HTTPS.
The connection was reset in HTTP which is what is expected.

5. What I already tried:

:80, :443, https://, http:// {
	abort
}

[francislavoie]

@Nicryc

SSL_ERROR_INTERNAL_ERROR_ALERT in HTTPS.

That’s normal. If the TLS handshake can’t be completed, then no HTTP handlers can run.

I’m not sure why you would want to do this though, you don’t need to explicitly block anything, Caddy will just not do anything with the connection by default.

You don’t need this at all:

@Nicryc

:80, :443, https://, http:// {
	abort
}

[Nicryc (Nicolas)]

@francislavoie

I’m not sure why you would want to do this though, you don’t need to explicitly block anything, Caddy will just not do anything with the connection by default.

Security reason I think. In my opinion it’s better to intercept and abort all unexpected connections. Besides an SSL_ERROR_INTERNAL_ERROR_ALERT error implies that the site exist and is running (but there is an error) while a The connection was reset error is more ambiguous and suggest that the site isn’t online or don’t exist at all.

@francislavoie

That’s normal. If the TLS handshake can’t be completed, then no HTTP handlers can run.

So is there a way to abort before the TLS handshake or skip it to abort the connection?

[Mohammed90 (Mohammed Al Sahaf)]

What are you trying to protect against exactly? Someone knowing an IP address has a web server behind it? Everybody can know that by merely running dig +short -x <ip address>. Someone pointing some random domain to your IP address? The web server will not serve anything to a hostname they’re not configured for. Nonetheless, the public already knows that particular IP address has a web server behind it.

What’s the gap you’re plugging?

[matt (Matt Holt)]

@Nicryc

The connection was reset error is more ambiguous and suggest that the site isn’t online or don’t exist at all.

I’ve got bad news for you… if the server didn’t exist, the TCP connection wouldn’t be reset; it wouldn’t be established at all.