Ssld,error ssl: record overflow, no common ciphers

RouterOS
1

Just today - I don't think I've ever seen messages like this - a RouterOS 7.23 stable system logged the following:

2026-05-28 12:01:01 ssld,error ssl: record overflow
2026-05-28 12:38:00 ssld,error ssl: no common ciphers
2026-05-28 16:43:57 ssld,error ssl: peer suggested unsupported TLS version
2026-05-28 18:43:22 ssld,error ssl: peer suggested unsupported TLS version
2026-05-28 18:43:55 ssld,error ssl: peer suggested unsupported TLS version
2026-05-28 18:44:28 ssld,error ssl: peer suggested unsupported TLS version
2026-05-28 18:44:28 ssld,error ssl: no common ciphers
2026-05-28 18:45:34 ssld,error ssl: no common ciphers
2026-05-28 18:46:07 ssld,error ssl: no common ciphers
2026-05-28 18:46:07 ssld,error ssl: peer suggested unsupported TLS version
2026-05-28 18:49:16 ssld,error ssl: peer suggested unsupported TLS version
2026-05-28 18:49:48 ssld,error ssl: no common ciphers
2026-05-28 18:49:49 ssld,error ssl: peer suggested unsupported TLS version
2026-05-28 20:00:37 ssld,error ssl: no common ciphers
2026-05-28 20:00:38 ssld,error ssl: peer suggested unsupported TLS version

The only thing open to the Internet is an SSTP server, and I don't see SSTP errors in the log around the time of these various ssld errors.

Searching, I don't find much at all (in the forum, or on the Internet in general) about these messages.

I assume - someone please correct me - that the RouterOS ssld is an underlying service which receives SSL/TLS connections for all RouterOS services which need to deal with SSL/TLS connections, and hands off the connection to the higher level service after successfull SSL/TLS session negotiation?

Is there a way to get the "ssld" to give some context for the connections that produce errors like these?

thanks,

2

I have the same errors on 7.23 but sstp works perfect i think thats "only" a attack port scan or something but it is ugly

3

I notice in the 7.23 release notes "added ssld error logging", so that probably explains why we're just now beginning to see these messages.

It still leaves the question of how to make the messages useful, as they do not contain any context.

(I agree with @Hagelsturm47 's idea that they're the result of scans/attacks; without context, they don't provide any value).

Searching on Pages - RouterOS - MikroTik Documentation for ssld finds nothing (literally: no hits at all from the search).

I set up /system/logging/add topics=ssld action=memory
This did not produce any further log entries.

Is there documentation for ssld somewhere? I don't find it on MikroTik's webpages.

-Jay

4

This error keeps popping up on different routers I manage ever since upgrading to 7.23

If anyone can let me know what is causing this, or how to remedy it , I would be grateful.

-tp

5

I'm also getting

ssl: record overflow

and

disconnected 43.158.111.*, ssl: record overflow

i have no idea what this ip represents.

It's annoying.

6

Almost without doubt, these are probes/attacks. The hope is that MikroTik's SSL implementation has no presently exploitable bugs...

This logging is new; the attacks certainly are not new. So, we're now aware of it, but they've been there always.

Still, these log entries need to provide more/useful information. I opened a support case with MikroTik about this fact; their answer:

We have forwarded the relevant information to our development team for review.
Unfortunately I cannot provide any guarantees of implementation or any clear ETAs.

7

@libove We would be very grateful if you could share the information you received with us, as these numerous error entries are becoming extremely annoying. :victory_hand:

8

@dezol Certainly, when I hear anything from MikroTik.

9

After upgrading to the new long-term release, 7.23.7, we are seeing the errors a lot too on our SSTP server hub.

I assume it is just probe attacks form the internet, thinking our router is a webserver or something. Maybe changing to another port than TCP 443 would make it stop, but that would ruin one of the things that make SSTP to reliable, disguising as HTTPS traffic.

The biggest issue with the error log message, is that it doesn't say the source connection of the error, so we don't know if it is coming from a legit source or random bot traffic. It would be more useful if it said the source IP-address or the username of the SSTP user that is trying to authenticate, or at the very least detailed which service is even trying to use the SSL daemon.

10

If you keep SSTP enabled and reachable, you should at least put it behind some port-knocking mechanism. It doesn't have to really use "ports". Here is one method that does not require complex tools or non-standard ports Rules against scanners - #36 by CGGXANNX.

11

I have a ticket open for similar - testing between unchanged, known good OpenVPN and ROS, iirc, 7.23.5 (maybe 4) and up has shown numerous non functional ciphers. aes-128-gcm and aes-256-gcm are the only ones currently working for me. Mikrotik has asked me for more info, which I have been tardy responding to due to knee surgery, but the bottom line is that they didn't dismiss the issue - something changed in ROS at that point making long term stable OpenVPN configs begin to fail.

Symptoms as seen from the client side are a hard disconnect by ROS. Changing the server in ROS (and client if needed) to known good ciphers has restored function for a couple of us hitting this issue.

While this isn't OpenVPN, the cipher issue may be common . . . .