TLS handshake error, client offered an unsupported, maximum protocol version of 301

Help
1

What can be done about this:
TLS handshake error from 94.23.204.183:55790: tls: client offered an unsupported, maximum protocol version of 301

I get this every 5 minutes on 4 different port numbers.

Caddy started with:
/usr/local/bin/caddy -agree=true -log=stdout -conf=/etc/caddy/Caddyfile -root=/var/www -email=<my_email> -pidfile=/var/run/caddy.pid

Caddyfile:

letbox.passchier.net {
        root /var/www/
        log stdout
        errors stderr
        gzip
        fastcgi / /var/run/php/php7.0-fpm.sock php
}

passchier.net, www.passchier.net {
        root /var/www/site/
        log stdout
        errors stderr
        gzip
        fastcgi / /var/run/php/php7.0-fpm.sock php
}

info.passchier.net {
        root /var/www/info/
        log stdout
        errors stderr
        gzip
        fastcgi / /var/run/php/php7.0-fpm.sock php
}

steun.passchier.net {
        root /var/www/steun/
        log stdout
        errors stderr
        gzip
        fastcgi / /var/run/php/php7.0-fpm.sock php
}

support.passchier.net {
        root /var/www/support/
        log stdout
        errors stderr
        gzip
        fastcgi / /var/run/php/php7.0-fpm.sock php
}

wedding.passchier.net {
        root /var/www/wedding/
        log stdout
        errors stderr
        fastcgi / /var/run/php/php7.0-fpm.sock php
}

http://trouwdag.passchier.net:80 {
        root /var/www/trouwdag/
        log stdout
        errors stderr
        fastcgi / /var/run/php/php7.0-fpm.sock php
}

lukas.passchier.net {
        root /var/www/lukas/
        log stdout
        errors stderr
        fastcgi / /var/run/php/php7.0-fpm.sock php
}

emmet.passchier.net {
        root /var/www/emmet/
        log stdout
        errors stderr
        fastcgi / /var/run/php/php7.0-fpm.sock php
}

wiki.passchier.net {
        root /var/www/caddywiki/
        log stdout
        errors stderr
        gzip
        rewrite /index.php /thaibible.md
        markdown {
                ext .md
                css /wiki.css
                js /wiki.js
  }
}

weblog.passchier.net {
        root /var/www/weblog/
        log stdout
        errors stderr
        gzip
        fastcgi / /var/run/php/php7.0-fpm.sock php
}

(The one http site is because I’ve run out of tls requests and apparently have to wait a week.)

2

It doesn’t seem very well documented, but “protocol version 301” here is actually referring to TLS v1.0, which is below Caddy’s default minimum supported protocol (as per the Caddy TLS docs).

You can get around this by upgrading whatever app is making requests to Caddy to a newer TLS protocol, or writing a TLS directive block that specifies a lower minimum protocol:

tls {
    protocols tls1.0 tls1.2
}
3

With all the above said, it doesn’t even look like Caddy should be listening on that port. My instinct would be to ignore these log entries as random chatter, and firewall off those ports unless you’re using them. Usually I firewall everything except 80, 443, and a few other ports (including a random port for SSH).

4

That’s not my IP address, the whois points to ovh.com.
What is that?? Is it sending a robot every 5 minutes? And why 4 entries??

I would prefer not to use tls1.0 but if this is not a sign of problems I can ignore it. It does litter up the logs, 4 entries like that every 5 minutes.

5

ovh.com is notably a popular provider of virtual private servers. It would not surprise me if one of their clients is utilising their service to scan locations on the internet for vulnerable targets, especially considering the connecting client’s insistence on an outdated, insecure protocol.

Again my advice is to firewall all incoming ports not explicitly in use. I would even consider configuring fail2ban to watch these logs and temp ban repeat offenders. This would have the added benefit of keeping your logs much clearer.

1 Like
6

I think @miekg has also reported similar log entries over at https://github.com/mholt/caddy/issues/1157.

Those port numbers are client port numbers, in other words, ports that your client is using to make the connection, not the ports on your machine (I think).

I don’t recommend enabling old versions of TLS.

2 Likes
7

I have a hunch this is an automated client using a too-low protocol checking my rss feeds… The start page service ustart.org is hosted on ovh.com

So I guess, this could always happen, someone trying to access stuff without being able to use tls1.1 or 1.2, so this must be par for the course. Happy it’s not something on my side.

8

After whois-ing a range of hosts on @miekg some of them might even be highly resource full players trying out security vulnerabilities…

9

I lowered the TLS minimum protocol on a very specific vhost because the Windows software ShareX only seems to support TLS1.0 when making PUT requests to my PHP upload handler. I’m not sure whether that’s a worse idea than simply downgrading to HTTP for these uploads, but I would like these uploads to be private, so…

Generally speaking I’d definitely have to echo @matt’s (lack of) recommendation.

10

Well, I changed the Caddyfile for the one host with the rss feeds and added:

tls {
    protocols tls1.0 tls1.2
}

Now I get this for each rss file access every 5 minutes:

94.23.204.183 - [20/Dec/2016:13:54:36 +0700] "GET /site/en_rss HTTP/1.1" 200 7222
94.23.204.183 - [20/Dec/2016:13:54:36 +0700] "GET /site/nl_rss HTTP/1.1" 200 7726

I guess that means it tries one more time in case of failure.

Could I only serve the rss files with these lower protocols and the rest of the host on a normal level? Ie. could I split the host up somehow??

11

Yes, although in that issue all request return that error, in essence deadlocking caddy (I’m still trying to debug that one).

Yes, what you see is the client port number so that is all normal. I would not be concerned about this errors, would be interesting to see what is actually doing this.

12

uhm?

[bogus text to make the post longer than 10 characters]

13

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