How does winbox “secure mode” authenticate the target RouterOS host? The wiki claims it uses TLS but I’ve never seen it prompt to accept a certificate or show a key fingerprint or similar. This seems like it would be vulnerable to a MITM attack on an unsecure network, kind of defeating the description of “secure mode”.
I guess it definitely would.
As the manual says also, “Keys exchanged using DH-1984, encryption using modified and hardened RC4-drop3072”.
Just that it doesn’t ask you to do this, doesn’t mean it doesn’t happen.
What exactly does or doesn’t happen? Please check the following list out:
- Session traffic encryption - happens (using modified and hardened RC4-drop3072)
- Session key exchange - happens (via Diffie Hellman exchange using a (non-standard???) DH group DH-1984)
- Server identity validation - does not happen
So, while WinBox session encryption does provide some protection against a passive eavesdropping, it does not in any way protects you from the MITM-style attacks.
Yes, you have outlined the current mechanism accurately.
Are there any plans to modernize this so it can be safely used over the internet or other untrusted networks?
- RC4 is broken and should be replaced with AES or another modern cipher.
- No mention of HMAC algorithm? Is one even used?
- I found no references to whatever “DH-1984” is, this should be replaced with a 2048 bit unique prime generated on install.
- Add host verification.
I’m not sure this even qualifies as TLS - it feels like home-made crypto which is very bad.
HMAC is usually only involved in the host verification procedure. No host verification- no HMAC needed/used. Just guessing.
Generated on install? How is that supposed to be used then? Are you sure you are not mixing DH group and host key up?
A HMAC is needed for authenticated encryption, otherwise there is no way to detect ciphertext modification with block ciphers like RC4 in common modes. A MITM could alter the ciphertext without knowing the corresponding input or output plaintext, potentially resulting in security consequences depending on the commands being sent (see https://security.stackexchange.com/questions/2202/lessons-learned-and-misconceptions-regarding-encryption-and-cryptology/2206#2206).
DH groups have a pre-computed prime field which is used for DH key negotiation. By using common or weak groups it opens the window for mass computation attacks that would compromise all devices using the same primes (see https://weakdh.org/). Generating a 2048 bit unique prime (DH parameters) at install makes mass computation pointless. Of course the host keys should also be generated at install time too!
This whole thing stinks of homemade crypto which likely hasn’t passed any kind of audit from a cryptographer. Get some real TLS in here!
RC4 is broken and should be replaced
That’s why I said “hardened”. It is not broken as the standard RC4 is. It is a custom variant.
Yep, I see your point. You’re right here.
DH group is not a secret, but rather a common knowledge- both sides of the secure connection are supposed to use the same prime+generator pair (DH group) in their key exchange computations. Generating a unique prime on install is rather pointless, and making sure it is cryptographically good enough is almost impossible during install.
But I must agree that using a custom (not independently validated) DH group is not good and should be avoided.
There is only one page of Google results for whatever “RC4 drop3072” is. You say it’s a custom variant, has it been designed or reviewed by a cryptographer? Why are there no academic papers on it? More importantly, why is Mikrotik designing their own crypto instead of using well tested and secure industry standards like TLS?
Wikipedia describes this in the section “Fluhrer, Mantin and Shamir attack”
http://www.wikiwand.com/en/RC4#/Fluhrer.2C_Mantin_and_Shamir_attack
Protocols can defend against this attack by discarding the initial portion of the keystream. Such a modified algorithm is traditionally called “RC4-drop[n]”, where n is the number of initial keystream bytes that are dropped. The SCAN default is n = 768 bytes, but a conservative value would be n = 3072 bytes.
We use RC4 because it is much faster when used without hardware acceleration.
Direct source: http://www.users.zetnet.co.uk/hopwood/crypto/scan/cs.html#RC4-drop
OK, so that protects from one attack from 2001. What about all the other attacks on RC4 on the wiki page you linked, some as recent as 2015? The cipher is just broken at this point. As evidenced by the recent CIA leaks, nation states are interested in the security of Mikrotik devices so it makes no sense to continue using ciphers that are known to be breakable.
If performance is a concern, look into Chacha20-poly1305, it’s not only secure but more performant than RC4.
Hi All,
i just tried to check self signed ssl using https://cryptoreport.geotrust.com/checker/ for the web service was running on my MikroTik RB750 6.39 and found this vulnerabilities:
RC4: Enabled
Vulnerabilities checked: BEAST
should this vulnerabilities be fixed? i’m waiting for it.
thanks.
Does “checked” mean “failed”?
Exactly the opposite. The above mentioned site lists the vulnerabilities it checked and passed. FAIL would be indicated clearly.
Therefore I asked…
Is it effective against MITM attack