I’m very excited to announce that we’re now allowing and preferring HTTPS on the website for beta testers. As you browse around, you should see most of your traffic going over HTTPS. This is currently on the website only; the mobile apps, client and studio are still using mostly HTTP. We plan to transition them to HTTPS in 2016.
Please reply here if you see any issues with content not loading (or causing a mixed content warning) on the website or functionality not working.
HTTPS is working for the main site and forums. Will we be getting this for the developer forums the same time or close to the same time as the full site?
Excellent question. Eventually devforums (along with blog, wiki, corp) will also be HTTPS. We’re more worried about the main website and gameplay at the moment. Once those are 100% HTTPS, we will make the security cookie SecureOnly, so it won’t be sent in clear text when visiting an ancillary roblox.com site that isn’t yet encrypted (or if you accidentally navigated to www.roblox.com over http).
What does this mean for people that create browser extensions for ROBLOX? What would we have to change in our http requests for getting data from the site?
You might want to redirect all HTTP to HTTPS, I can still access the HTTP version just by removing the “S”, some basic MITM programs are due to this still possible to sniff the cookie.
For now, we’re trying to push beta testers to HTTPS by rendering all URLs to the page as absolute (or most of them) with https:// at the begining. If you go directly to a page over HTTP, it will still work. After we feel pretty good that everything is working over HTTPS, we will roll out the same change to all users. Finally, we will begin redirecting all traffic that comes in on HTTP to HTTPS. At that point we’ll also upgrade the cookie(s) to SecureOnly and probably add headers to prevent HTTP traffic to the main site (for browsers that support it).
From a browser extension standpoint there are some options: if you have a reference to the main website (like you are redrawing it), just use the protocol the site is using; // can work well, or a relative path. If you are making arbitrary requests to the website, I would recommend adding a switch to your code now to allow you to upgrade to https requests when you start seeing them on your non-beta-tester accounts (or when we announce we’re rolling HTTPS out for everyone). Even if you do nothing, your requests will most likely continue to work; requests will eventually be redirected (using either a 301 for GETs or 307 for POSTs) to https. If you’re using api.roblox.com, you can just go ahead and upgrade to HTTPS now; it already supports both.
Yes, please support HSTS (I assume this is what “add headers to prevent HTTP traffic to the main site” refers to) and add ROBLOX to the HSTS preload list! I submitted a pull request adding a ruleset to HTTPS Everywhere for api.roblox.com, and I’ll add the other subdomains as they become available with HTTPS for everyone.
I don’t understand what you mean. Neither of them redirects to HTTPS for me, both support HTTPS, and both should redirect to HTTPS once HTTPS is made the default.
Both the www and the uk don’t auto-direct to http://, but all links in the page link to the https:// version.
(Isn’t that what they did? Make the links https:// for beta testers?)
Indicates it doesn’t automaticly redirect to the HTTPS version (yet).
Well, there you have it. Just had to scroll a tiny bit lower than the first quote.
I don’t know too much about DNSSEC, but a quick check does not show a lot of adoption from major websites (google, Apple, Amazon). Is it really a thing?
ICANN’s policies require signing for all new top-level domains, and almost all the existing ones support signing, including .com of course. Google Public DNS does DNSSEC validation. All websites of the US government are required to support DNSSEC (see the memorandum from 2008 and https.cio.gov). More interesting is that according to stats.labs.apnic.net, 15% of domain names have valid DNSSEC records as of September 2015. In November 2015, CloudFlare enabled DNSSEC support for all the domains it manages (millions of websites); you can read the post DNSSEC Done Right by the DNS extensions IETF working group chair, hired by CloudFlare to work on the universal DNSSEC support.
I have a local DNSSEC-validating DNS resolver, but I am not representative of most ROBLOX users for sure. I think what really matters is the benefits DNSSEC would have for ROBLOX. At the moment, I think that’s mostly that it prevents DNS cache poisoning. It might prevent attackers, rogue ISPs or malware installed on a user’s computer (in cases where validation is done in the browser, as it sometimes is) from doing phishing attacks, redirecting roblox.com to another website, etc.
In particular, it prevents attacks manipulating the DNS records for phishing, injecting ads or making a website unavailable. These attacks are usually done by DNS cache poisoning, where an attacker tricks (with a man-in-the-middle attack, for example) a DNS nameserver into storing invalid records in its cache. The nameserver will then return these invalid records to everyone who asks for them until the cache expires, which can mean all the customers of an ISP. From what I’ve read, it seems this happens mostly for smaller ISPs or ISPs in non-western countries.
Whether DNSSEC is worth adding for ROBLOX depends mostly on how difficult it would be to add, and that’s something only you can know.