Many "First record does not look like a TLS handshake"

Help
#1

Hi all !

I had a Caddy server running in a Docker container with both http and https working for months.
I recently updated to the latest Caddy and updated some internal virtual networks.
As soon as:

  • At least one of my HTTPS website is defined in the Caddyfile
  • My router port 443 is forwarded to Caddy’s port 443

There are then tens of errors like the following, per second:

2018/09/19 20:08:12 http: TLS handshake error from 172.22.0.1:48004: tls: first record does not look like a TLS handshake
2018/09/19 20:08:12 http: TLS handshake error from 172.22.0.1:48006: tls: first record does not look like a TLS handshake
2018/09/19 20:08:13 http: TLS handshake error from 172.22.0.1:48012: tls: first record does not look like a TLS handshake
2018/09/19 20:08:13 http: TLS handshake error from 172.22.0.1:48014: tls: first record does not look like a TLS handshake
2018/09/19 20:08:13 http: TLS handshake error from 172.22.0.1:48016: tls: first record does not look like a TLS handshake
2018/09/19 20:08:13 http: TLS handshake error from 172.22.0.1:48018: tls: first record does not look like a TLS handshake
2018/09/19 20:08:13 http: TLS handshake error from 172.22.0.1:48020: tls: first record does not look like a TLS handshake
2018/09/19 20:08:13 http: TLS handshake error from 172.22.0.1:48022: tls: first record does not look like a TLS handshake

Oddly it works, I can access my HTTPS website, but it seems to make latency to access the network very bad for other programs running (i.e. 8 seconds for Google). Plus I don’t like my log to be filled with errors :wink:

I also tried:

  • Running on the host without Docker or virtual networks
  • Deleting certs etc. for my HTTPS website and re-verifying them (works)

Would anyone has any idea or suggestion to help me out?

Thank you all !!

#2

Those errors simply indicate broken clients which are trying to connect to your HTTPS port without using TLS. There’s nothing you can do about it except block them.

2 Likes
#3

Notably, 172.22.0.1 is a private address. Docker uses similar addresses for bridge networking (usually you’ll see 172.17.0.0/16 as a default, but it can branch out - anywhere in 172.16.0.0/12 is valid for private internets).

You might be able to investigate internally and find out which client or service is responsible for the repeated access requests, and fix its configuration.

Tens of failed access attempts per second should not impact a modern network significantly. There might be other issues at play, especially if latency is eight seconds higher than expected.

2 Likes
#4

I have turned off my Caddy over night and it works perfectly this morning. It must had been someone trying HTTP on the HTTPS connection indeed, but Docker made it hard to verify from where it was coming from (172.22.0.1 was the network gateway). Thanks for the quick help !!! :+1:

1 Like
#5

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