449

Update 2017-05-22

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.


Update 2017-03-16

We've redirected all child meta traffic from meta.*.stackexchange.com to *.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 aware of HTTPS Everywhere users getting too many redirects here, and unfortunately the issue is with their ruleset. I have submitted a PR to resolve this here: EFForg/https-everywhere/#9110

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.


Initial post

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!

Given the above, we need to see how all of this works in practice with real load:
We're starting with meta.stackoverflow.com and meta.stackexchange.com.

Here's an order of things that's been going on (per site):

  1. done Infrastructure in place:
    • A fast CDN/Proxy for local termination (Fastly)
    • Certificates (including IP pooling support to bridge HTTP/1.1 & HTTP/2)
    • Logging
  2. done Get third-party support in place:
    • All per-site scripts onto our CDN and served securely
    • Ad providers to HTTPS
  3. done Fix a ton of code that assumes http:// in a million places.
  4. done Prevent users from embedding new http:// content (e.g. forcing HTTPS images).
  5. done Cleanup all existing user content that was http:// (https:// where possible, and converted to links if we can't embed it securely).
  6. done Make sites render absolute URLs as https://.
  7. done Move canonical URLs to https://.
  8. done 301 Traffic to https:// for all.
  9. done (Child metas) Move from meta.*.stackexchange.com to *.meta.stackexchange.com.
  10. Force all Q&A traffic to https:// (and set an https-only cookie)
  11. Migrate all existing sessions to secure sessions (this will take time to run).
  12. Use HSTS to ensure browsers don't hit Q&A sites via http:// at all.

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:

  1. done meta.stackoverflow.com
  2. done meta.stackexchange.com
  3. done security.stackexchange.com (why? This community is well equipped to test HTTPS concerns and give feedback)
  4. done meta.security.stackexchange.com (moving to security.meta.stackexchange.com)
  5. stackoverflow.com
  6. done Q&A network main sites except stackoverflow.com (e.g. *.stackexchange.com, superuser.com)
  7. done Stack Overflow localized child metas (e.g. meta.ja.stackoverflow.com moving to ja.meta.stackoverflow.com)
  8. done Q&A network child meta sites (e.g. meta.*.stackexchange.com)
  9. done stackexchange.com (the top level non-Q&A domain)
  10. done area51.stackexchange.com
  11. (Planning required) chat.stackoverflow.com, chat.stackexchange.com, and chat.meta.stackexchange.com

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.

  • 10
    For 11. chat, how about you migrate chat.so to chat.se and have a problem less? – Braiam Mar 8 '17 at 14:51
  • 19
    @Braiam That's not really a problem less, it's the same solution for all 3. However, it would create a ton of problems merging 3 databases, room lists, users, code assumptions, figuring out redirects for all time, etc. It's just not a win in any way :) – Nick Craver Mar 8 '17 at 14:52
  • 1
    On the Google thing, they made this big deal about how it helps SEO and yet there's no indication it helps much, if at all. So the fact that WMT doesn't support it correctly doesn't surprise me either. Google wants HTTPS, but not badly enough to make it easier for people to make it work – Machavity Mar 8 '17 at 15:00
  • 8
    Do you want bug reports as answers to this, separate questions tagged bug and ssl, or something else? – ale Mar 8 '17 at 15:20
  • 7
    There's a minor content security-related bug for the editor preview that may have been missed for #3. TO THE WHEEL OF BLAME! – Tim Stone Mar 8 '17 at 15:25
  • 6
    @ale Answers here are fantastic, thanks! – Nick Craver Mar 8 '17 at 15:30
  • 1
    The Hot Meta Posts (on meta.SO itself) are not linked with https (not sure if caching, but it's been a while). – Floern Mar 8 '17 at 17:04
  • 2
    How are you planning on moving the metas to site.meta.se? Will you have the Community bot go around editing them, or will that be on the users to edit their posts? – Riker Mar 8 '17 at 17:35
  • 1
    @NickCraver I'm getting sticky HTTPS from here on MSE to other sites. E.g. I come here and it rewrites the URL to HTTPS, I use the supercollider to go elsewhere, URL stays HTTPS, and then when I go to that other site's meta I hit the cert error. I gather that's not intended behavior? I'm seeing it in Firefox 51.0.1 and reproduced in a private window. I am not using the HTTPS Everywhere extension. – Monica Cellio Mar 8 '17 at 22:46
  • 3
    Followup: doesn't happen on Chrome 56.0.2924.87. Maybe a Firefox bug? (I'm not sure I want to use IE to break a tie...) – Monica Cellio Mar 8 '17 at 22:52
  • 1
    @PeterMortensen What's "this"? Pretend I know nothing about your super secret always-encrypted programming language :) What's breaking? Does the lib not support HTTPS at all or something? Or...another issue? – Nick Craver Mar 9 '17 at 1:30
  • 1
    Answer: it's SOUP. – Monica Cellio Mar 9 '17 at 3:12
  • 1
    @PeterTurner Nick's kind undeletion aside, I think it was correctly deleted, as it does not answer the question which is looking for specific technical issues with SE's HTTPS rollout. It would be more appropriate as a separate meta question than as an answer here. – Xander Mar 10 '17 at 17:13
  • 1
    You might want to add a Content-Security-Policy-Report-Only header so that users will automatically report mixed content and similar issues. You could also add an upgrade-insecure-requests CSP header, though that's not ideal until you're done with everything else. – Brian Mar 11 '17 at 20:25
  • 1
    @John It's not completed yet -- they still have to migrate SO, stackexchange.com, Area 51, and chat. They also need to do #10-12 on the first list. – NobodyNada Mar 30 '17 at 1:50

40 Answers 40

2

All of the child meta sites are giving me a redirect loop in Chrome when I navigate to them from the top menu. I have already deleted all my browsing history (and had to login again after that) without any result. It works fine in Firefox and Internet Explorer 11, but Chrome (which I use for 95% of my browsing) gives a redirect loop error.

  • Are you using HTTPS Everywhere? If so, this is caused by one of their rules and I've submitted a PR to fix it here: github.com/EFForg/https-everywhere/pull/9110 – Nick Craver Mar 17 '17 at 11:01
  • @NickCraver Actually, yes I am. Weirdly enough, I did read the other answer when checking if noone else had the issue, but I didn't make the connection and thought it was due to some cached redirect rule on my end. – Nzall Mar 17 '17 at 11:54
2

Profile page pictures don't show up when using the https:// versions of the site. Nevermind, this seems to be that Gravatar had lost the PG version of my profile pic - it has the G version and others, but SE is trying to load the &r=PG version. I've fixed that


Additionally the hyperlink when clicking on the picture (or rather where the picture should be) redirects to the http:// site.

Example:

Non-HTTPS Picture

On the profile page as well, I've the SE flair in my profile. Other people also have images in their profiles. Currently this is still using the http:// link. I have updated that now manually, but I was wondering is it worth all pictures in profiles being automatically updated to https:// links where available?

  • we don't default codegolf to https yet – m0sa Mar 20 '17 at 9:05
  • @m0sa the profile is network wide, so the last paragraph still applies to SO and SU. When I went in to change the profile it did say only HTTPS images allowed, but I assume it would make sense that those are changed over automatically just like Q&A. On sites like EE.SE/Codegolf/whatever, if you navigate to the HTTPS site, all links on the profile page except for the profile image one are staying on the HTTPS version of the site. That's why I assumed it was a glitch. – Tom Carpenter Mar 20 '17 at 9:25
  • 1
    @TomCarpenter The link is http:// because the site doesn't default https:// yet. The picture is https://...that's a separate Gravatar issue. We're discussing how to move off of them internally now, as they don't seem to care all of their stuff is breaking left and right anymore. As an example, your Super User profile does link to https://, because it has switched over. – Nick Craver Mar 20 '17 at 12:25
2

It is suggested by @Adam that this can be fixed when full HTTPS support is rolled out network-wide.

  • I don't think it is proper to re-post a bug report here as answer. Having it either as answer here or a separate report is enough. – Shadow Wizard Mar 27 '17 at 20:42
2


I was trying to add a comment to Worldbuilding's writing a blog post about TRAPPIST-1. What should we include in it? (asking whether it’s time to un-feature it, so not too important). However, the red notification “An error occurred while adding this comment” appears instead, and the browser console shows these mixed contents warnings (in German):

screenshot of browser warnings

  • Do you have a screenshot of the errors handy? Thanks! – Adam Lear Mar 28 '17 at 22:42
  • 1
    @Adam Lear: Added, but it’s in German. :) The problematic thing for posting the comment is the second line from the bottom, the URL ending in /comments. – chirlu Mar 28 '17 at 22:52
2

With the deployment of https I see a huge drop in StackOverflow referral traffic in the analytics of our own site. Many of the links in SO that point to our site were written when we had no https equivalents (we've moved to https a while ago, though). Since by default referral information is not passed from https to http sites, the information now gets lost and I see a decrease by a factor of about 20 in the referrals. That's not really a big problem, because people are probably still clicking on the links and are being successfully directed to our site, however they do not appear in analytics anymore and StackOverflow suddenly dropped dramatically in the referral ranking, which is sad from the analytics point of view.

Would it be possible to employ the "unsafe-url-referrer-policy" on SO sites? That would reenable referrers for links that are still targetting http sites.

  • 2
    Think it's worth of a new feature request. – Shadow Wizard Jun 28 '17 at 14:41
1

When I visit meta.math.stackexchange.com I get:

Your connection is not private

Attackers might be trying to steal your information from
meta.math.stackexchange.com (for example, passwords, messages, or credit 
cards). NET::ERR_CERT_COMMON_NAME_INVALID
  • Where did you get a link to that? The site is math.meta.stackexchange.com - the old meta address never worked under HTTPS (and likely never will). – Nick Craver May 29 '17 at 1:01
  • @NickCraver I just added meta to the beginning – Noah Cristino May 29 '17 at 10:23
  • @NickCraver But, now it's working fine, it just redirects. – Noah Cristino May 29 '17 at 10:24
1

Old chat links to Meta posts, like the oneboxes from feeds, have been migrated from HTTP to HTTPS, but the domain change isn't processed.

An example is this chat message. The history shows the original link was

http://meta.gaming.stackexchange.com/questions/12010/please-dont-vote-to-close-spam-questions

but it's now

https://meta.gaming.stackexchange.com/questions/12010/please-dont-vote-to-close-spam-questions

which gives an SSL error. It should be

https://gaming.meta.stackexchange.com/questions/12010/please-dont-vote-to-close-spam-questions

instead.

1

When linking to insecure third party images, the embedding in chat causes mixed content warnings. I guess a fix involves rehosting images on i.stack.imgur.com (if feasible) and stopping the embedding of all other insecure content.

0

Links from Help Center to Meta Stack Exchange

It seems that many links from Help Center to Meta Stack Exchange are http rather than https.

I've noticed this when looking at Help Center > Privileges > Access To Moderator Tools

See also: http://meta.stackexchange.com/questions/5221/how-does-deleting-work-what-can-cause-a-post-to-be-deleted-and-what-does-that

The link given there is http rather than https and it is shown as url rather than as the post title. (The same link is expanded to the full title in a post to the full title, even if I post is with http: http://meta.stackexchange.com/questions/5221/how-does-deleting-work-what-can-cause-a-post-to-be-deleted-and-what-does-that)

EDIT: Correction to the preceding paragraph - it is expanded in the preview, but it is no longer expanded after I post an answer. This seems to be another bug - but I guess this must have been noticed and reported before. With https it is expanded both in preview and in the actual post: How does deleting work? What can cause a post to be deleted, and what does that actually mean? What are the criteria for deletion?

After that I checked a few other entries in help center. As far as I can tell, all links to Meta Stack Exchange are http and not https. But I did not find example similar to the above. (In the entries I looked at, those links were displayed as some text rather than as a bare url.)

  • I hope this is the correct place to posted something like this. Originally I posted this as a separate question, but since is probably a better place, I have deleted that question. – Martin Apr 27 '18 at 8:07
-61

What I don't understand is why this site needs ssl. Is it just to avoid getting hassled by web browsers? I've been using stackoverflow for a long time, since the beta, has anyone been hacked? The personal details page is not much of a life-history, and aside from careers, it doesn't store enough information about us to even make accessing that particularly useful.

I would much prefer a micro-revolt against this trend toward ubiquitous SSL, no mom-and-pop restaurant with a hundred-dollar-per-year home-built static website advertising their menu wants or needs to have an SSL tax foisted upon them and it should be up to us, the programmers of the world, who can see a tad clearer about these things than the corporate bigwigs, that should do whatever we can to avoid them and reclaim sanity.

Basically, it makes no sense to encrypt this text therefore it should not be encrypted. It is a waste of processing power and bandwidth.

Based on the comments, and what I know about this technology (and I only have years of hands-on experience, you can tell I'm not an expert in any useful sense) is that

  1. You wanted http/2 features.
  2. You can't get them without https.
  3. The reason you can't get it without https is because the browsers are against it.

What I read from that is that browsers (cough Chrome) are against it because it is in their best interest to be the only thing between your eyeballs and the webpage. People don't trust the ISPs (whose service they pay for), but they do trust Google, whose purpose is to sell you stuff... Tell me again why we're falling for this?

  • 39
    You can get SSL certificates for free easily now (Let's Encrypt). Moderator accounts for example are much more critical as they have access to PII, but are vulnerable to certain kinds of attacks while SE doesn't use SSL. SSL also prevents certain kinds of obnoxious behaviours from middlemen like ISPs adding ads to pages. – Mad Scientist Mar 9 '17 at 15:50
  • 29
    I think you're overestimating the computational cost of SSL. For sites pushing large amounts of static data (e.g. netflix or youtube) it makes a small but noticeable difference. For stackoverflow rendering the page should be significantly more expensive than encrypting it. – CodesInChaos Mar 9 '17 at 16:08
  • 7
    Can you demonstrate that the environmental concern is valid? Given that the additional processing load was down to negligible levels even when only considering HTTP processing 10 years ago, in the grander scheme, I strongly suspect it's too small to measure at all today. – Xander Mar 9 '17 at 16:08
  • 24
    HTTP 2 pretty much requires HTTPS support. We've seen that it makes a huge difference. It is also helps users who's ISPs inject content into the page - with HTTPS that can't happen. There are lots of good reasons to use it. – Oded Mar 9 '17 at 16:44
  • 28
    Better security, less bandwidth, faster response times (HTTP/2), better privacy, protection from injections. As for your initial post, there are a lot of bad assumptions there. Our site's energy footprint is tiny. In NY use about 16kVa of energy (Denver uses far less). That's about 130 100w light bulbs, or lighting for a small company. We take great pride in our efficiency and the remarks on energy impact are baseless. The impact on our numbers likely won't be even be big enough to measure. – Nick Craver Mar 10 '17 at 17:31
  • 8
    HTTP and HTTPS are layer 7 concerns, routers are dealing with layer 2 and 3. HTTPS is faster because every major browser decided that HTTP/2 features are almost exclusively enabled on secure connections. This isn't part of the spec, but how browsers do it and ultimately all that matters. With HTTP/2 we can push resources to the client faster for example, rather than waiting for another request to get the CSS, etc. That requires HTTPS. There are several purposes and you're willfully ignoring them, but I'm not sure why. – Nick Craver Mar 10 '17 at 17:55
  • 17
    @PeterTurner You don't get around this with multiple domains. You're likely talking about concurrency limits which is an entirely different thing. Push is a new HTTP/2 feature effectively gated by HTTPS. To be frank: none of what you are saying is true. And saying all websites should go opposite to what browsers are doing (both exist to serve users) is just absurd. Again, that makes no sense at all. – Nick Craver Mar 10 '17 at 18:11
  • 12
    HTTPS is far more important than just avoiding "getting hassled by web browsers." Ever heard of Firesheep? If I'm sitting in a coffee shop and not using HTTPS, anyone could get access to my account. – NobodyNada Mar 10 '17 at 19:24
  • 6
    @PeterTurner I'm not sure why you think web browsers are the enemy. The reason they "hassle" us to use HTTPS is because of attacks like Firesheep. Encryption is the only way to get privacy and security on the Internet, and the drawbacks of using HTTPS are next to zero as other commenters have explained. – NobodyNada Mar 10 '17 at 19:41
  • 16
    Honestly, given the numerous exploits ISPs have deliberately perpetrated against their paying customers, and the exactly zero exploits deliberately launched by any browser maker I've heard of against their free users, I haven't the foggiest why anyone would trust ISPs to boil water without introducing a new backdoor. – Nathan Tuggy Mar 10 '17 at 20:32
  • 6
    @PeterTurner: I don't know what you're trying to say, exactly, as I don't use IE, Edge, or Chrome, and all browsers allow changing default search engines, and general browser usage is not where Google and Bing get their ad targeting, and tracking is a far cry from actual malware. (Also, my local mom-and-pop ISP hijacks DNS responses to inject parking pages.) – Nathan Tuggy Mar 10 '17 at 21:28
  • 7
    @PeterTurner it's inherently bad for performance, which I've covered and will provide aggregate data to back up in the blog post. Also also cookie access, proxy caching, etc. But you seem to want to just ignore all the arguments you don't agree with here, that's not a healthy or productive avenue of discussion in any situation. – Nick Craver Mar 12 '17 at 0:38
  • 7
    @PeterTurner yes how terrible Chrome is forcing my browsing data to be private, and stopping 3rd parties exploiting http. how annoying !? – Tim Mar 13 '17 at 6:37
  • 23
    -1 for "I need more downvotes". I got your back, man! – Ogre Psalm33 Mar 13 '17 at 17:35
  • 7
    @PeterTurner Straight from the horses mouth, Adam Langley (from Google) posted back in 2010 statistics on SSL overhead on his blog. To quote him directly SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Offset that with the fact that HTTP2 speeds up connections by over 50% in most instances, you've actually gained performance overall. It all comes down to whether the benefits of SSL offset the "1%" loss in performance, and in this case the answer is overwhelmingly yes. – jduncanator Mar 14 '17 at 23:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .