Could anyone help me by answering which version of TLS protocol MikroTik uses for the encryption in secure mode when using winbox? I have a system which needs to be PCI DSS compliant, and one of the requirements is to encrypt all non-console administrative access (if using TLS protocol it is mandatory to use at least v1.1, preferably v1.2).
I have searched the forum and all over the net but haven’t found this information.
Trying to get certified here too. You can check for SSL or TLS version support with the openssl s_client on Linux or maybe Cygwin if you’re on Windows. Type “man s_client” on your Linux to get more information about this.
Will check if the handshake can be done with TLSv1.0.
The ordering for the versions is the following (at least AFAIK):
SSLv1 (never actually released)
SSLv2 (insecure)
SSLv3 (insecure)
TLSv1.0 (accepted, but read below …)
TLSv1.1 (accepted, but read below …)
TLSv1.2 (secure)
TLSv1.3 (draft, not released, but of course will be secure)
TLSv1.0 and TLSv1.1 will be accepted it seems until 30 June 2016 (you can go with it now if a “Risk Mitigation and Migration Plan” is in place), date after which you’ll need to write a Compensating Control for it and check if the implementation is not broken in your particular case (a mess, IMO).
That being said …
It would be awesome if someone from Mikrotik can answer if SSL/TLS versions can be enabled/disabled at will, either on the GUI or via CLI.
Issue with certifications like PCI DSS comes from the fact that you need to certify that your system component (an MT router in our case) doesn’t allow insecure versions of SSL/TLS, being that over the webfig administration interface (HTTPS) or via winbox. It’s required to not allow fallback to insecure versions, that is, you should not be able to connect with anything that is NOT secure enough (forced by the device, not the client connecting).
Mikrotik should add or provide a way to control which SSL or TLS mode is accepted in configuration.
Also, not strictly related to this post, but people trying to get certified will also have issues with the SSH daemon, since it doesn’t allow the following values to be configured (from the openssh-server daemon running on most Linux machines, IDK what MT runs):
And also only DSA keys supported ? No RSA keys ? I don’t think it should be that hard to support these parameters, which a lot of people in enterprise environments will surely appreciate to have.
Hhmmm, what about Webfig? I can connect perfectly using https, but when I try https, I get the old “You need to enable crappy, insecure protocols to access this website” message (yes, I enabled www-ssl in ip/service). I get the same issue trying IE11 (Win 10) and Chrome ver 47 - neither of these support the older SSL protocols and it seems Webfig doesn’t run TLS 1.x (preferably 1.2).
I just set up SSL for webfig with a letsencrypt certificate and it’s working just fine.
But I also want to harden the SSL / HTTPS service, so I did a vulnerablitiy scan and the results telling me there are some vulnerable / old protocols and ciphers still active.
Is it possible to disable TLS 1.0 / TLS 1.1 or disable specific SSL / HTTPS ciphers?
'Weak' cipher suites accepted by this service via the TLSv1.0 protocol:
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
'Weak' cipher suites accepted by this service via the TLSv1.1 protocol:
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
'Weak' cipher suites accepted by this service via the TLSv1.2 protocol:
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
Thanks Normis,
Sounds like it should be a default setting, with an option command to downgrade if necessary (vice the current default to what seems to be an old standard??), but then I know diddly squat about security architectures and standards.
TLS 1.2 was defined in RFC 5246 in August 2008.
TLS 1.3 was defined in RFC 8446 in August 2018.
Is there a plan to update the TLS version in RouterOS to TLS 1.3?
We should have TLS1.3 as an option to select when… YESTERDAY.
I believe that protocol makes perfect forward secrecy mandatory when selected so that will create additional firmware work to implement.
It would be nice if MT actually stated approx when its expected to hit the road map.
TLS 1.3 has significant advantages like:
TLS 1.3 offers significant performance improvements over previous versions. The connection setup requires only one round-trip (versus two for TLS 1.2) and includes an option called 0-RTT (zero round-trip) which allows users to revisit websites without renegotiating encryption. This results in faster loading times for secure web pages.
From a security standpoint, TLS 1.3 abandons obsolete and unsecured features present in TLS 1.2 (such as SHA-1, RC4, DES, 3DES, AES-CBC, MD5) in favor of more secure alternatives (including ChaCha20, Poly1305, Ed25519, x448, and x25519). Additionally, TLS 1.3 encrypts most of the handshake process, providing better privacy and flexibility for future protocol evolution.