Disable HTTPS redirect

WD just posted the announcement below, but due to their transparency and willingness to listen to their users(irony), they always close the topics.

Does anyone know if it’s possible to disable the redirect and set the https port back to 443?

1 Like

@WDStaff We need you to know that this is not ok. We need you to understand WHY this is not ok. We really need you to understand that we’re not going to stop asking for this to be removed. Finally, we need you to understand that you are going to lose customers as a result of this feature, and that people like me have already begun leaving bad reviews on your products across multiple retail sites as a result.

We want to be able to access our devices locally. We want to be able to do so without authentication through your web service. Saying “if there’s no web access it allows you to do it locally” is not an acceptable answer.

There needs to be an option to remove or disable this functionality. I need to be able to access my device without being logged out frequently by your auth service.

Please provide a date for when this feature will be removed, updated, or improved in a way that will allow us to access our devices using the methods we have availed of since purchase and up until the roll out of this terrible feature.


Thank you for sharing your concerns about the HTTPS functionality on My Cloud OS 5. Using HTTPS for the Admin dashboard provides significantly better security in that it encrypts the connection between your browser and the dashboard, including passwords and any other sensitive configuration data. To address a few of your specific points:

  • All HTTPS access to the Admin dashboard is performed directly between your browser and your My Cloud NAS on the local network.
  • You can verify that Admin dashboard access is local by using the “ping” command to resolve the domain name shown by your browser when accessing the dashboard.
  • Authentication to the Admin dashboard on your My Cloud OS 5 device is performed locally. Logging in to the Admin dashboard does not involve any cloud-based authentication.

Good to have this explanation.

This question has been asked numerous times in the last few weeks.

I am very confused on one point: If all the access and encryption is local. . . . .why does this process require internet access to function? Is it merely to provide DNS resolution from your local ipaddress (or device friendly name) to that-big-long-thing using HTTPS? How does that work if you ever change your local IP address or the device name of the OS/5 machine?

I generally use and for DNS lookup (can’t check my OS/5 machine at the moment). These are not WD DNS servers. . . so these should work?

I am not an expert at this. . . so I remain slightly confused.

1 Like

Because your OS has to resolve the name to your local address and your browser has to validate your NAS certificate against the Certificate Authority.

Technically we were safer when we had a self-issued certificate (that shown https error) because no one had the private key, but now that WD has our private key (they generate the certificate request to Let’s Encrypt), if they wanted they could make a copy of our authentication traffic and read your password.

Please, guys, let your technical team participate in the discussions here. We want to help you to improve your product. Otherwise, I’ll keep telling people on Plex and Reddit forums to not buy your NAS.


1 Like

But still, with https redirect each time we access a url on our private device you know it! Why? One should have the option to accept the risk of a privately issued certificate!!!

yeah. . . .I am getting to the point where I am going to permanently block internet access to the OS/5 device at the router.

Unfortunately, in my system this action also blocks the router’s access to other subnets within my network. . . and as a result I will lose VPN access to the machine. Oh well.

Thanks for the question! We’re always happy to respond to users who are interested in learning about how our latest security improvements work. As it happens, the only way to obtain a certificate that is accepted by web browsers is to assign a domain name that can be verified by the certificate authority (in this case, Let’s Encrypt). Without a valid certificate, you would receive a certificate error from your browser whenever you attempted to access your device via HTTPS. As you stated, the Internet access requirement for HTTPS is used only to set up and maintain the DNS record that points at your device’s local IP address. If your device IP address changes, the device will send a request to our name service to update the record for your device and point it at the correct IP address for your device. This causes an updated DNS record to be published at our DNS provider, which is currently Amazon Web Services Route 53. This is a form of “Dynamic DNS”, which you can read more about here: https://www.cloudflare.com/learning/dns/glossary/dynamic-dns/

When your browser requests a DNS lookup for device-local-XXXXXXXX.remotewd.com, the lookup is sent to your choice of DNS resolver. In your case, you are using Google DNS ( Google’s DNS resolver performs what is called a “recursive lookup” to find out the IP address for your device, starting at the domain servers for the “.com” domain. The request is then sent to our DNS provider (AWS Route 53 at the moment), which then looks up the record for your device. If you’re interested in learning more about how DNS lookups are performed, we found a good reference document here: https://www.cloudflare.com/learning/dns/dns-server-types/

Once your browser has found the My Cloud device through its DNS name, it connects directly to the device via HTTPS on your local network and loads the authentication page where you enter your admin username and password. That username and password is sent directly to your device on the local network and is now encrypted through the HTTPS connection. The “big long thing” in the domain name certainly looks strange, but it has a purpose as well. We assign a random identifier to your device to thwart attackers from being able to guess the name of your device. This helps keep your device private and secure by limiting the amount of information that anyone can find about your device.


Please let us provide our own (local) signed certificate and key, or at least let us disable this “service”.


Again, which only you have the private key. Thank you very much for taking the time to answer us, that’s a first!!! I hope you guys bring FREEDOM to OS 5, because we can’t change anything, and LIFE, because there are way too few apps.


Thank you very much for this detailed explanation.
Explanations like this really do go a long way in building confidence and trust from your user base. There have not been nearly enough of this since the release of OS/5.

However. . . .regarding the HTTPS Security certificate. . … I am not a fan of this feature.
In my view, the best way to avoid suffering from a man-in-the-middle attack is to not put a man-in-the-middle for authentication on intranet communication.

If I recall OS/5 correctly, you already block access to the Admin Web interface from the internet. Is that not enough? Do I need HTTPS for intranet communication?

These are not Enterprise level NAS units. If someone is accessing my network. . . that means they have likely

  • compromised the router; in which case I doubt the HTTPS connections to the NAS are secure OR
  • are physically in my house; in which case they can just walk up to the NAS and do a 4 second reset. or just unplug the unit and take it home with them.

I agree an option for us to create our own local certificate; or to disable the HTTPS access would be valuable.

1 Like

We’re happy to engage in constructive conversations with our users about My Cloud OS 5. Responses from Western Digital’s Product Security Incident Response Team (PSIRT) come from our technical team of security engineers and incident response managers. A number of the statements made in this thread about how My Cloud OS 5 works are not accurate and we’d like to take the opportunity to clear up any confusion users may have about how HTTPS access to your device works.

Western Digital does not have the private key used for HTTPS connections to your NAS. Certificate issuance for the My Cloud OS5 device uses the ACME protocol to request a certificate from the Let’s Encrypt certificate authority. The private key used for your device is generated on your My Cloud NAS and always stays on your My Cloud NAS. The ACME protocol uses a “challenge-response” system to verify your device and issue the certificate, and this takes place using the Dynamic DNS system that Western Digital operates. In general, the process of obtaining a TLS certificate never requires that you share your private key with anyone. For more information on how the ACME protocol works, see the Let’s Encrypt web site: https://letsencrypt.org/how-it-works/

Western Digital does not have access to, intercept, or “man-in-the-middle” authentication to your My Cloud Admin dashboard. Authentication to the My Cloud NAS device takes place directly between your browser and your NAS device. The domain name that is shown when accessing your NAS resolves directly to the local IP of your NAS and does not imply that your NAS device is being accessed through Western Digital servers. We have provided information in this thread on how you can verify this for yourself.

There are multiple reasons why HTTPS is beneficial for access even when communicating to the NAS device on the local network. Web browsers are steadily evolving to warn users when communicating with devices over unsecured HTTP. Currently, Google Chrome marks all HTTP sites as “Not Secure” in the user interface and warns users when entering passwords on HTTP pages (https://blog.google/products/chrome/milestone-chrome-security-marking-http-not-secure/). This has the effect of potentially confusing users when they access their My Cloud device, even when it is being accessed locally. Browsers also treat self-signed certificates as critical security warnings. Using a valid certificate prevents both of these issues and provides users with assurance that the connection to their NAS device is as secure as possible.

Additionally, malware targeting IoT devices such as IP cameras and NAS devices continues to evolve and may soon be capable of attacking one IoT device from another compromised device on the local network. The principle of Zero Trust Security suggests that encryption should be used even on the local LAN. For more information on Zero Trust Security, see: https://www.csoonline.com/article/3247848/what-is-zero-trust-a-model-for-more-effective-security.html

My Cloud devices are used by a broad variety of customers in many different use cases and applications, from home users to small businesses. The security improvements in My Cloud OS 5 are designed to keep our users ahead of the evolving network security landscape. Our goal in My Cloud OS 5 was to provide additional security for our customers based on current best practices and the implementation of HTTPS security was driven by that goal.

1 Like

First thanks for a very well thought out response. It is a very good answer corporations certainly like to hear…


Any software regardless of IT Security measures and guidelines can and almost surely does have unknown flaws so why would I want that exposure if I can avoid it without any loss of functionality? TLSv1.0 would be my first example of a “now” broken security standard. Any old encryption algorithm like DES, WEP 64 which there are very many. SMBv1 would be another and there are many many more. Could ACME be another ?

Regardless of the security aspect I still would like the option for local access to dashboard.

So what happens when my internet provider is DOWN ? I would like to be able to access my NAS from my computers even if my internet connection is down. This is very important as if/when our internet connection is down we would still like to administer access on my NAS. And yes I could setup a home DNS / bind Linux server and deal with creating trusted certificate nonsense but why should I go through that hassle if I could just have local dashboard access as an option.

1 Like

Thanks for explaining. Now turn back on direct access without this feature. Provide us a way to disable it. We now know what it is, how it works, why you did it, and we don’t want it.

What is the timeline for a firmware release that will remove, disable, or give us the option to circumvent this feature? Please be specific.


They said in another thread previously that it will revert to direct non-https connect, proving that the functionality still exists to do so and they just won’t let us use it that way by default… even though that’s what we want!


Whatever your explanations and reasons are, since this implementation my surveillance cameras don’t have access to my disks anymore. There are, from the camera stand point, no ways to bypass your new HTTPS thing.
I need from WD the option to disable this very soon.
Moreover since this upgrade the remote backup doesn’t work either.

Thanks to tell us when this bug will be fixed.

1 Like

I suppose that we all fall into a user - customer group. And a quite peaky one. I agree. On the other hand members of this user - customer group are the most probable to suggest or not specific products to friends, family or business. It will be good to have them happy.

We do not argue against the solution you provide. We state that we would like the freedom of options! Let us decide what we want, redirect or not. It should not be such a huge hack to turn redirection off. Or just provide the details and I am sure that a lot of people in this group will go on and do it themselves.

Personally I am happy that after so many years an upgrade came to mycloud. It seems that these changes can bring a new era to our devices and the solutions that we can build on top of them.

I do not feel though that a strategy of denying any suggestions or requests from the most demanding part of your customer base is one that will safeguard your middle to long term strategy.

The optimal solution in any problem is the one that allows you the most options into future situations.I I hope you can see what we are asking for. The simple ability to deactivate redirecting. (Personally I would really love the option to tweek the Fan speed on a PR4100 in order to keep my HDD cool, but this is a different discussion)

thanks in advance

fu man tsu


Again; a very good answer from @westerndigital-psirt. This does clear up a number of issues in my mind.

So I clearly had it wrong in regards to “man-in-the-middle” in terms of authentication. However. . . you still have a third party doing the DNS resolution. Now - - -I am clearly not sophisticated to suss out the implications of that step.

@thetick: I definitely share your security concerns. My understanding (and I think I have tested this at one point) is that if the NAS is blocked from the internet. . the system will default to a HTTP connection within your network?

So I started having questions when other users began to report frequent communication between the NAS and “somewhere”; and that this contact was happening even if cloud access was turned off.

Question: Is the reported internet activity merely the NAS signally it’s a ip address to make this redirect work? How often does that occur?

Followup Question 1 Imagine a user that does not care about WD Web/phone apps and cloud access is disabled. Is there any on other internet communication to/from the unit?

Followup Question 2 If a user does not care about WD Web/phone apps; and the user uses an external firewall to block internet access to the NAS. . . .what other functionality/capability will the user lose on the NAS (i.e. what other surprises are there)

Thanks for your help on these matters

1 Like

The admin page redirect isn’t done server side via 302, it’s done client side in Javascript. So we’re relying on the client correctly parsing the javascript for an insecure page, then redirecting to a secure page.

Admirable, but you expose the “secure” URL to any un-authenticated user at: http://<insert_your_nas_ip_here>/nas/v1/locale.

It would be pretty easy to javascript scan a network for that endpoint, exposing the secure hostname, and now an attacker can go generate a valid keypair; using the same secure service you’ve exposed to all customers. This is pretty much a textbook example of security through obscurity?

All we’re asking is, please, let us have the option to disable it.

I guess one possible way of blocking this (in Chrome anyway), would be to disable image loading for the NAS admin page:

img.onload = function(){
top.location.href = redirect_url;

Just tested this, and yup. Blocks the redirect. Phew, a workaround!


I too found a way to block this using uBlock Origin, huzzah!

You must have advanced mode turned on in the extension settings and then when you navigate to YourIP for your NAS you configure the settings like this:

Once this is set, using direct links like MyIP/apps/transmission/web/transmission.html works without having to go through the admin panel and navigating to the app configure first too! Great success!

1 Like