Hi,
RouterOS 6.48.6 (long-term)

In short: Is there any way to disable less secure (RC4, 3DES) ciphers on www-ssl service? Something like /ip ssh set strong-crypto=yes ?

Explanation:
One of my customers is subject to PCI DSS quarterly vulnerability scans. They sent me a report which enumerates several problems with www-ssl service (Webfig over TLS). The report is in general very poor, it enumerates vulnerabilities which seems to be fixed since at least in ROS v6.13 (CVE-2013-0169, see below) or vulnerabilities without indicating any CVE (or other indication of validity of supposed vulnerability) at all, but the one I want to address is use of weak ciphers. Even if I use (set) address property or use firewall to limit IPs accessing https port that does not mitigate entirely attack on those weak ciphers.

The report states that we use weak TLS/SSL ciphers: CVE-2016-2183 (64-bit block ciphers) and CVE-2013-2566 (RC4 cipher alg.). I have already set but nmap still enumerates some weak ciphers (I've omitted ciphers with A rating):
Qualys SSL Labs report goes even further labeling all RC4 ciphers as just insecure.

There was a thread How to disable weak ciphers and hmac in TLS? in Forwarding Protocols forum that got no conclusive answer (and there was no ROS version indicated).

As for CVE-2013-0169 (aka. Lucky13) it was side-channel timing attack affecting openssl in versions prior to 1.0.1e, 1.0.0k or 0.9.8y. But I found that normis announced that Heartbleed (CVE-2014-0160) is not an issue on ROS v6.13 and above as they use newer, not affected version that is at least 1.0.1g or 1.0.2-beta2. So 1.0.1g had already fixed Lucky13 issue and I assume Mikrotik did not use beta branch of openssl.

In short: no.

Explanation:
The configurations services must be never exposed to internet.
Qualys SSL Labs must access the device over internet.
Is clear that all this importance with security, but all is leaved exposed, mean nothing.

You can run SSTP server (which is not configuration service and in most cases needs to be accessible from anywhere) and you'll have same problem (edit: similar problem, there you have additional Force AES and PFS options to play with). So it still would be nice to have this configurable.

I'm talking about PCI DSS, or SSL Labs just as reference for what is considered secure and what not. I have sites where LAN in fact is less secure than Internet because my responsibility ends at RJ45 ports of the device (even if client seeks or pays for additional advisory on lan side we can not consider it "more" secure). I'm talking about this scan only because I forgot to setup appropriate firewall rules, and it showed up in report and its results were surprising. Weak ciphers are issue I'd like to resolve. There is no excuse. If there is option to use only tls1.2 then weak ciphers (esp. RC4) are to be disabled. So I'll rephrase my question to:

Does Mikrotik plan to disable weak TLS ciphers in any foreseeable future for long-term releases (seems like security/maintenance update)? Or enable more fine grained control over cipher suites used with TLS (seems more like feature request that need proper staging)?

No offense, rextended, but following your logic: Why bother with ssh or TLS anyway if we can use telnet via dedicated lan port? Or even why use passwords at all? Just lock the device in inaccessible room/cabinet and allow administration only via console port for whomever has a physical key to that room/cabinet? Well then I'll have to have to employ several dozens of local service staff whose salaries will blow the budget so much that instead I could just go straight to leased private fibers and pay-me-for-everything-and-forget-the-rest vendors.

Sob: yes but this is workaround and if I have to do workarounds I would go for IPsec vpn which at least gives me very precise tuning options.

Do you use the services in any way provided by the web server? If do not then disable it. If you only use it for admin purpose then make sure it is only accessible from specific networks or hosts where the scanner is not part of that.
Then ask for a rescan and problem should be solved from a report perspective.
As far as I know there is no way to temper with settings of the we server.

No offense, rextended, but following your logic: Why bother with ssh or TLS anyway if we can use telnet via dedicated lan port? Or even why use passwords at all?

Offense? No problem
But you can't follow my logic: I don't use webfig at all, it's disabled, no matter what protocol, encryption or whatever...
(and I also do not use telnet)

Not gonna hold my breath... just look at the problems with the outdated ssh-rsa public key signature algorithm which Mikrotik have known would be an issue since 2020. Unfortunately things have to break before they will be fixed. Please prove me wrong Mikrotik and release a big crypto update that removes all these obsolete / insecure ciphers!

On one of latest releases (I do not remember the number) are already removed...
Search on changelog...

THe most volnerable mikrotik "product" are the user:
no weak cyper, but management port telnet, winbox, api, all exposed to internet without firewall, with username admin and password P@55w0rd...

On one of latest releases (I do not remember the number) are already removed...

Still, such security updates should also find their way to long-term release. It's common and expected practice. I can not put my devices on testing, and recent events also do not encourage stable branch for production environment.

THe most vulnerable mikrotik "product" are the user:

And yet it does not mean we can ignore issues just because a user will screw everything up in the end. If device does good job then it is up to the user to not break it, but this does not work the other way.

Ignoring any NON encryption bugs, you have to explain to me how an "attack" on webfig on port 443 in TLS 1.3 strict
can be less dangerous than on port 80 in clear text.
It is always and in any case the interception of traffic between the browser used and the device.
Better get browsers out of the equation altogether, do not publish the WebFig on public internet, and use one VPN (please... not the pptp......) with SSH or WinBox.
Also because if a browser is trivially infected, it absolutely does not care if it uses SSL 0.1alpha or STLSS 5.88


It is perfectly useless to follow the latest cryptography if the passwords are still saved in a password.txt file on the desktop...
(and on PC still run Windows 7)
EDIT: (and on PC still run any Windows)

Since TLS 1.3 dropped support for 3DES and RC4, I think all we need is a "tls-version=only-1.3" option.

One of my customers is subject to PCI DSS quarterly vulnerability scans. They sent me a report which enumerates several problems with www-ssl service (Webfig over TLS).

What is doing the scanning and why does it have access to the Mikrotik admin interfaces?

"Zero trust" is a common model used by serious organizations. You should not assume your management VLAN is secure, if one device is compromised an attacker should not be able to leverage their network position to move to other devices. So even internally-facing devices and open ports need to be properly secured.

One of my customers is subject to PCI DSS quarterly vulnerability scans. They sent me a report which enumerates several problems with www-ssl service (Webfig over TLS).

What is doing the scanning and why does it have access to the Mikrotik admin interfaces?

The auditors often requires and asks for access to all networks or vlans to perform their scans.

I recommend disabling all services that doesn't need to be running. Use SSH instead of Webfig/Winbox.