Anyone else using chisel server seeing this? Solution?

Client dev
1

We have multiple certs that we got at the same time, so obviously if someone was to query one they would see the rest. We host a chisel server (wraps ssh / reverse ssh in tls) on the public inet - on the chisel server side we are seeing a ton of traffic like:

TLS handshake error from IP:PORT: acme/autocert: missing server name

which we are sure are just bots and such scanning us, the traffic were seeing and have questions on is:

TLS handshake error from IP:PORT: acme/autocert: host "anotherregistered.domainbutnotthechisel.domain" not configured in HostWhitelist.

Since we run CT servers we have a pretty comprehensive list (in the low thousands) of a large amount of the CT servers and such, and none of the IP's have matched any we know of. Since were seeing HostWhitelist showing up to us this essentially ensures us that its LetsEncrypt autobot or similar - so we were planning on auto white listing these IP's for 15 days or so, then dropping the ACL until we see the IP again. Or as its highly likely after fully testing chisel we'll fw this port to only allow our subnets - we were planning on a (pre)check for HostWhitelist (although somewhat of an issue pre-checking to add a ACL before the packet hits the kernel [depending which way we go] as of the OSI layer its at). We do our auth via DNS, this is via HTTPS, and the hosts queried tend (~75-~85%) to be for domains that are not currently accessible/up.

Is this something to be concerned about, or take it more as a low level warning, or just ignore? None of our certs have been effected at all so we're basically leaning to the ignore option. Just asking as Id be happy to learn anything about it.

If LetsEncrypt would list their subnets, even if they have a /28, /30 etc and just post it as a /24 that would really help with whitelisting - but that doesnt appear to be happening anytime soon.. thought Id toss that in there :wink:

2

Then Let's Encrypt is not sending HTTP or TLS-ALPN requests to your domain. If using an HTTP Challenge you will see multiple challenge requests with HTTP on port 80. If you redirect that HTTP request LE follows it. For a TLS-ALPN challenge also multiple challenges but using tls-alpn on port 443.

Let's Encrypt does not send any legitimate requests to your domain except in response to an ACME Client cert request from your system.

Once you obtain a cert it gets logged in public Certificate Transparency logs. Bad actors scan these logs for the domain names in the cert to use as targets for attacks. Nothing you can do about that apart from hardening your server.

3

Other users can request certificates for your domain or redirect http-01 requests to your domain, it's just that the requests are unsuccessful.

4

Yes, fair point. I had "legitimate" in that sentence in an early draft so I think I'll put that back in.

5

Oh damn youre 100% right - up until you mentioned that we had always thought if we saw HostWhitelist is was coming from LetEncrypt (obviously anyone coding anything could have - but that detail made it seem unlikely to us.). Once you mentioned that we went looking and found it was a policy function used in a bunch of automatic TLS managers (Echo web for ex). Thanks, that actually clears it up and helps up quite as bit as we were going to code to accommodate it... naively.