465

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.

Improve this question
62
  • 11
    For 11. chat, how about you migrate chat.so to chat.se and have a problem less?
    – Braiam
    Commented Mar 8, 2017 at 14:51
  • 21
    @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 Mod
    Commented Mar 8, 2017 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
    Commented Mar 8, 2017 at 15:00
  • 9
    Do you want bug reports as answers to this, separate questions tagged bug and ssl, or something else?
    – ale
    Commented Mar 8, 2017 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
    Commented Mar 8, 2017 at 15:25
  • 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
    Commented Mar 8, 2017 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?
    – user311528
    Commented Mar 8, 2017 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
    Commented Mar 8, 2017 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
    Commented Mar 8, 2017 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 Mod
    Commented Mar 9, 2017 at 1:30
  • 1
    Answer: it's SOUP.
    – Monica Cellio
    Commented Mar 9, 2017 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
    Commented Mar 10, 2017 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
    Commented Mar 11, 2017 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
    Commented Mar 30, 2017 at 1:50
  • 1
    @Nick what about stackpromos.com?
    – Shadow Wizard
    Commented Aug 6, 2017 at 10:45

42 Answers 42

Reset to default
1
2
4

Links to comments (I didn't check for another stuff) in Stack Exchange Data Explorer should be fixed for persite metas. E.g. from meta.ru to ru.meta:

meta.ru

Tested in this query for ruSO.meta.

Improve this answer
3
  • 1
    Proper bug report here
    – rene Mod
    Commented Oct 26, 2017 at 16:03
  • @rene looks like that bug is fixed. In my case there is https already.
    – αλεχολυτ
    Commented Oct 26, 2017 at 16:14
  • On second thoughts this is better raised as a specific bug for sede
    – rene Mod
    Commented Oct 26, 2017 at 16:20
4

We have also rebaked links inside the network (except comments) to point to the new domains and protocol.

I still see http:// links in Super User posts.

E.g. in my question, Advertisement suddenly appearing on top of almost every page, the original http:// links (e.g. the http://superuser.com/q/831994/213663#832990) are still http://.

Unless I misinterpret the above statement.

Improve this answer
1
  • 1
    superuser links were processed just now, including your example
    – m0sa
    Commented Mar 20, 2017 at 10:19
4

The total page views from the moderators dashboard in Meta Stack Overflow in Spanish (Stack Overflow en español) does not show any data at all.

Improve this answer
3

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

Improve this answer
2
  • Do you have a screenshot of the errors handy? Thanks!
    – Adam Lear StaffMod
    Commented Mar 28, 2017 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
    Commented Mar 28, 2017 at 22:52
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.

Improve this answer
2
  • 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 Mod
    Commented Mar 17, 2017 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
    Commented Mar 17, 2017 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?

Improve this answer
3
  • we don't default codegolf to https yet
    – m0sa
    Commented Mar 20, 2017 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
    Commented Mar 20, 2017 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 Mod
    Commented Mar 20, 2017 at 12:25
2

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

Improve this answer
1
  • 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
    Commented Mar 27, 2017 at 20:42
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
Improve this answer
3
  • 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 Mod
    Commented May 29, 2017 at 1:01
  • @NickCraver I just added meta to the beginning
    – Noah Cristino
    Commented May 29, 2017 at 10:23
  • @NickCraver But, now it's working fine, it just redirects.
    – Noah Cristino
    Commented May 29, 2017 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.

Improve this answer
1
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.

Improve this answer
1

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.)

Improve this answer
5
  • 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
    Commented Apr 27, 2018 at 8:07
  • I guess this is fixed...
    – Random Person
    Commented Feb 20, 2022 at 18:54
  • Here is a separate post related to http-links in the help center: Help has non-HTTPS links in it
    – Martin
    Commented May 13, 2022 at 2:07
  • Martin, this has been fixed, right?
    – Random Person
    Commented Sep 12, 2022 at 16:31
  • 1
    @RandomPerson Basically, yes. From what I was told by Yaakov Ellis, if some pages in the help-center have been customized for a particular site, those ones has to be fixed manually by the moderators.
    – Martin
    Commented Sep 14, 2022 at 2:55
-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?

Improve this answer
51
  • 40
    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
    Commented Mar 9, 2017 at 15:50
  • 30
    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
    Commented Mar 9, 2017 at 16:08
  • 8
    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
    Commented Mar 9, 2017 at 16:08
  • 25
    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 StaffMod
    Commented Mar 9, 2017 at 16:44
  • 30
    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 Mod
    Commented Mar 10, 2017 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 Mod
    Commented Mar 10, 2017 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 Mod
    Commented Mar 10, 2017 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
    Commented Mar 10, 2017 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
    Commented Mar 10, 2017 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
    Commented Mar 10, 2017 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
    Commented Mar 10, 2017 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 Mod
    Commented Mar 12, 2017 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
    Commented Mar 13, 2017 at 6:37
  • 24
    -1 for "I need more downvotes". I got your back, man!
    – Ogre Psalm33
    Commented Mar 13, 2017 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
    Commented Mar 14, 2017 at 23:07
1
2

You must log in to answer this question.

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