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".

This seems like it would be vulnerable to a MITM attack on an unsecure network.

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.

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:

1. Session traffic encryption -happens(using modified and hardened RC4-drop3072)
2. Session key exchange -happens(via Diffie Hellman exchange using a (non-standard???) DH group DH-1984)
3. Server identity validation -doesnothappen

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.

• No mention of HMAC algorithm? Is one even used?

HMAC is usually only involved in the host verification procedure. No host verification- no HMAC needed/used. Just guessing.

• I found no references to whatever "DH-1984" is, this should be replaced with a 2048 bit unique prime generated on install.

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 (seehttps://security.stackexchange.com/ques ... /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 (seehttps://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.

A HMAC is needed for authenticated encryption, otherwise there is no way to detect ciphertext modification with block ciphers like RC4 in common modes.

Yep, I see your point. You're right here.

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 (seehttps://weakdh.org/). Generating a 2048 bit unique prime (DH parameters) at install makes mass computation pointless.

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.

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.

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……mir_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/c ... l#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 usinghttps://cryptoreport.geotrust.com/checker/for the web service was running on my MikroTik RB750 6.39 and found this vulnerabilities:should this vulnerabilities be fixed? i'm waiting for it.

thanks.

Does "checked" mean "failed"?

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