Please add HTTPS support on mikrotik.com

Hello,
I’ve noticed during my browsing that there is no HTTPS deployed on the site.

The main mikrotik.com site is particularly vulnerable since it hosts downloadable .exe files (winbox, netinstall, etc) which are not digitally signed, allowing a MITM to deploy trojans / malware.

The upgrade feature in winbox makes insecure requests to upgrade.mikrotik.com, allowing a MITM to push fake updates onto administrators.

Given the availability of free certificates from Let’s Encrypt, there is no barrier to deploying SSL / TLS any more. Could you look into supporting HTTPS across the domain? Thanks.

I think that certificate is not a matter of price for mikrotik.

I know, I’m just pointing out that HTTPS is easy and free these days, to the point where some webservers even have it built in with ACME.

agree with this… :sunglasses:

I can tell you that there are several companies that have lost my business because their sites are not full HTTPS.

Just because they’re not supporting encrypted connections doesn’t mean there’s no security or compensating controls. Think about it…you’re not downloading any sensitive information, so there’s really no reason to encrypt it. MikroTik does provide a hash sum for the downloads, so you can verify the integrity of whatever you download. You’re right that it’s easy to set up an HTTPS site, and it’s free/not expensive to get a valid certificate, but why go through the effort when there’s no sensitive data being transmitted, and there’s a method in place to validate the integrity of the files? If you’re not transmitting personal, financial, or otherwise sensitive info, it’s just unnecessary.

How do you know the MD5 is real if the page is not HTTPS ?

But this IS sensitive data - it’s the very operating system of a networking device! If someone were to MitM your connection to the Mikrotik site, and provide a malicious version of RoS, you’d never know. They would be able to back-door your network, or monitor for cleartext pii, credit card numbers, passwords, email addresses, etc.

Without SSL (or some other form of cryptographic identity verification system) then you cannot be certain that a remote host is actually the host you intended to communicate with. This renders the MD5 checksum useless as a means of verifying your download. It is trivial for the MitM attacker to generate their own valid MD5 hash of the compromised image as well. Since there’s no way to know that the checksum came from a trustworthy source, the MD5’s not worth the paper it’s printed on, so to speak (at least as far as verifying security is concerned).

I think I just saw the worst example, which is a mess of HTTPS-lessness, dubious domain redirections, USA toll free numbers and so on.

Yes and no. You’re right that someone could MitM the connection, provide a fraudulent MD5 sum, and get away with it. You’re wrong that there’s no way to verify the source. MT could implement DNSSEC (or have their DNS providers implement it - not currently implemented according to my tests) to sign their domain. This would provide validation of the authenticity of the source. As you could then trust that you were communicating with the proper website, this would also provide a level of trustworthiness regarding the MD5 hashes.

It would be a best practice to just go ahead and use TLS to protect client connections…it would solve a lot of security related issues with minimal effort, but as with most things, there’s more than one way to skin a cat.

DNSSEC only makes sure that hostname resolves to right address (if the proper validation is done), so it’s not possible to redirect client to some completely different server using DNS. But MITM does not need that, attacker is already in the middle, on the wire, he can see and alter anything non-encrypted.

There are multiple types of MitM attacks. DNSSEC does provide MitM protections for cases of DNS spoofing/session redirection, but not for other types of MitM like browser hijacking. All of your speculation about the security of MT’s site is based on specific scenarios you have engineered in your mind. Not all possible scenarios will occur the way you are thinking. You shouldn’t take absolutist views on a subject that has so many permutations that it’s impossible to address each one.

Understand, I’m not saying MT shouldn’t beef up their security…at the very least, they should run their downloads over TLS (preferably v1.2 or better), but there’s not need to secure their entire site with SSL/TLS. It would be smart for them to have their domain signed for DNSSEC, as this would provide complementary security versus SSL/TLS alone.

Then again, if any of us REALLY had a problem with the fact that MT isn’t doing this already, none of us would be on this forum, or purchasing their equipment, etc. So if you’re an active MT product/forum user, remember it’s YOUR CHOICE to use these products and this website. Your continued use of their products says that despite any whining you do here about the security of their site, it’s just not important enough to you to make you switch to a different company’s products.

I think it is very common to buy from a company the first time, only to discover later that the support/update/removal process is not secure.

Of course…we’ve all been there. But if it was that important of an issue, we’d have already taken our business elsewhere by now. Ask yourself this…if R1CH hadn’t made a posting about the lack of HTTPS support, would you have made this comment…?

And the idea that you’d steer your business elsewhere because the WHOLE site wasn’t HTTPS is a little ridiculous. There’s no need for HTTPS on portions of websites that don’t serve sensitive data. Many websites simply implement HTTPS on everything because it’s easier and gives their customers peace of mind, but the only place it would really be required is on the downloads to ensure the integrity of the files. Even there, it wouldn’t be necessary if all the files were digitally signed. Their authenticity and integrity could be validated without the need for encryption on the file transfer.

I think we’re all getting pulled onto the bandwagon because one person wasn’t happy about the lack of HTTPS support. Not that they’re wrong, MT should do better, but I think this is getting overblown a bit.

What I mean by “full HTTPS” is that a certain process was not fully secure, not that the whole thing needs HTTPS.

But it better have HTTPS for things like downloading PDFs.

All it takes is one unencrypted page and someone can MITM and rewrite all the https link to http and break https for the rest of your session. It really does need to be all or nothing.

They could make a sandbox with hijacked SSL links but they couldn’t put the Mikrotik cert on their SSL sandbox. (You do look at the cert when you visit your financial websites, I hope)

Any site that hosts a malicious web page is in danger of having its certificate revoked so I would think that a redirected SSL site wouldn’t have a valid cert - at least not for long, but one really should glance at the certificate info when visiting secure sites anyway…

My only point is that software is definitely something that is important to verify.

Just to point it out, the RouterOS files are all signed and you can’t make your own packages, or replace them with fake ones. They would simply not be accepted in the software.

Good to know. Knowing that your products validate the signature before installing updates should be a great relief to those who were worries about ROS getting hijacked. Unless your code-signing private key gets compromised, we don’t need to worry about hacked versions of ROS making their way onto our equipment.

Yes. This has always been so. No need to worry.