stackoverflow.com is now
https://. I've written up a lot of what it took to get here in a blog post.
Next up is chat and then
https-only cookies. We'll be ramping up HSTS
max-age directives as we go. I'll continue to update this post as we deploy new bits.
We've redirected all child meta traffic from
*.meta.stackexchange.com, and are now forcing HTTPS. We have also rebaked links inside the network (except comments) to point to the new domains and protocol. We'll get to comments at the end.
We are pausing further migrations while we observe how google handles sites like Super User over the next week or so. I'll be back from vacation on March 27th and we plan to deploy
Content-Security-Policy-Report-Only headers for reporting and proceed with full Q&A deployment across all main sites then.
This is a heads up, and a request for help. Related: original post from our test site, Meta Stack Overflow.
HTTPS for our entire network is long overdue, but we've been working hard on it behind the scenes. Expect a pretty big blog post when we turn it on everywhere that details the journey.
There are a few lingering questions on HTTPS we're not confident in until we do it live. One of these is the Google site move in webmasters. It still (to our disbelief) treats HTTP and HTTPS as different properties. I have no idea why. And the "change of address" tool doesn't support such a move either:
Note: The tool does not currently support the following kinds of site moves: subdomain name changes, protocol changes (from HTTP to HTTPS), or path-only changes.
So we'll have to create property sets for every single site during the move to HTTPS. Fun!
Here's an order of things that's been going on (per site):
- done Infrastructure in place:
- A fast CDN/Proxy for local termination (Fastly)
- Certificates (including IP pooling support to bridge HTTP/1.1 & HTTP/2)
- done Get third-party support in place:
- All per-site scripts onto our CDN and served securely
- Ad providers to HTTPS
- done Fix a ton of code that assumes
http://in a million places.
- done Prevent users from embedding new
http://content (e.g. forcing HTTPS images).
- done Cleanup all existing user content that was
https://where possible, and converted to links if we can't embed it securely).
- done Make sites render absolute URLs as
- done Move canonical URLs to
- done 301 Traffic to
- done (Child metas) Move from
- Force all Q&A traffic to
https://(and set an https-only cookie)
- Migrate all existing sessions to secure sessions (this will take time to run).
- Use HSTS to ensure browsers don't hit Q&A sites via
This is a really high level list, and there are a crazy number of nuances and edge cases to the above. This is for Q&A. Area 51, Chat, and stackexchange.com (the main site) have a separate set of concerns and code we'll address after Q&A. The list also isn't necessarily in order. While we're testing #6, Samo and I will be working on #11 at the same time.
But we have to do all of this across the network, and we're starting that process now.
meta.stackoverflow.com was our testing ground this week. While we're still waiting for Google's analytics to catch up so we can assess impact, we're ready to go on a few more sites. Here's our rough list:
security.stackexchange.com(why? This community is well equipped to test HTTPS concerns and give feedback)
- done Q&A network main sites except stackoverflow.com (e.g.
- done Stack Overflow localized child metas (e.g.
- done Q&A network child meta sites (e.g.
stackexchange.com(the top level non-Q&A domain)
- (Planning required)
We want your help simply reporting any issues with insecure content on
https:// or any other oddities you see. We'll try to address them as soon as possible. Since we get asked this a lot, yes - I'll write an exhaustive blog post about everything we hit along the way when we're finished here.